/irc-logs / w3c / #css / 2013-09-05 / end

Options:

# Session Start: Thu Sep 05 00:00:00 2013
# Session Ident: #css
# [00:00] <plinss> SimonSapin: yeah, that's doable
# [00:00] <plinss> (maybe)
# [00:01] <plinss> anybody know how that file is generated?
# [00:07] <plinss> nm, found it
# [00:09] * Joins: rhauck (~Adium@public.cloak)
# [00:12] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [00:35] <fantasai> TabAtkins: What time do you think you'll get in tomorrow?
# [00:35] <fantasai> TabAtkins: Also, have all relevant people been pestered wrt Dael?
# [00:35] * fantasai wants to see if we can get her processed this week
# [00:35] <TabAtkins> yes, relevant people have been.
# [00:35] <fantasai> yay
# [00:36] <TabAtkins> she won't be processed this week - it'll be *next* monday, after the f2f, that she'll get the offer, assuming everything goes right (which I'm pretty confident it will at this point).
# [00:36] <fantasai> *sigh*
# [00:37] <fantasai> fine
# [00:37] * fantasai disappointed :/
# [00:38] <TabAtkins> sorry. :/
# [00:39] <fantasai> TabAtkins: anyway, ETA tomorrow?
# [00:39] <TabAtkins> ~10:30, assuming my bike gets in on time.
# [00:39] <fantasai> kk
# [00:39] <TabAtkins> otherwise I'll bike to the caltrain and be a bit later
# [00:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [00:56] * Joins: rhauck1 (~Adium@public.cloak)
# [00:59] <fantasai> TabAtkins: kk, shoot me a text once you know
# [00:59] <TabAtkins> yup, will do
# [00:59] <fantasai> TabAtkins: I'm out between 11:15 and... probably 1pmish
# [01:00] <TabAtkins> kk
# [01:01] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [01:01] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:14] * leaverou_away is now known as leaverou
# [01:15] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [01:20] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [01:20] * jdaggett_ is now known as jdaggett
# [01:27] * heycam|away is now known as heycam
# [01:31] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [01:32] <SimonSapin> TabAtkins: could Bikeshed get rid of biblio.ref entirely and rely on Sheperd’s data?
# [01:33] <TabAtkins> No, Shepherd doesn't have all the information that biblio.ref does, and it has way less documents in it, some of which are depended on by current specs in the CSSWG and under bikeshed.
# [01:33] <hober> or the other xref data out there (anolis', or darobin's/respec's)
# [01:34] * Quits: lmclister (~lmclister@public.cloak) ("")
# [01:36] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [01:36] * jdaggett_ is now known as jdaggett
# [01:44] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:45] <TabAtkins> I want to pull in respec's xref data as well.
# [01:45] <TabAtkins> And anolis too, while we're at it.
# [01:47] <TabAtkins> fantasai: The bike repair dude won't be back on campus tomorrow until between 1 and 4. :/
# [01:47] <TabAtkins> And I'll be in SF on Friday too.
# [01:47] <TabAtkins> And then I'll be in Paris.
# [01:53] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [02:12] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:12] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:13] * Joins: glenn (~gadams@public.cloak)
# [02:18] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:19] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:36] <fantasai> TabAtkins: Can you get someone to pick it up and lock it near the office for you?
# [02:36] <TabAtkins> They'd have to pay for it for me too. :/
# [02:38] <fantasai> Is that a major problem?
# [02:41] <TabAtkins> Hm, let me check.
# [02:43] <TabAtkins> Nah, people I'd trust with it are in meetings all afternoon.
# [02:43] <TabAtkins> I also just realized that tomorrow is both our All-Hands, *and* Chrome's 5th birthday party.
# [02:45] <TabAtkins> So I guess I have to cancel tomorrow.
# [02:46] <fantasai> ok
# [03:04] * Joins: zcorpan (~zcorpan@public.cloak)
# [03:11] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [04:01] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [04:16] * Joins: glenn (~gadams@public.cloak)
# [04:21] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [04:26] * Joins: cabanier (~cabanier@public.cloak)
# [04:59] * Joins: rhauck (~Adium@public.cloak)
# [05:08] * heycam is now known as heycam|away
# [05:43] * heycam|away is now known as heycam
# [05:49] * Joins: lmclister (~lmclister@public.cloak)
# [05:56] * Quits: lmclister (~lmclister@public.cloak) ("")
# [06:23] * Joins: glenn (~gadams@public.cloak)
# [06:33] * Joins: lmclister (~lmclister@public.cloak)
# [06:43] * Quits: lmclister (~lmclister@public.cloak) ("")
# [07:25] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [07:53] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [08:20] * Joins: teoli (~teoli@public.cloak)
# [08:47] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:56] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [09:11] * Quits: Ms2ger (~Ms2ger@public.cloak) ("bbl")
# [09:56] * heycam is now known as heycam|away
# [10:02] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:02] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [10:02] * Joins: zcorpan (~zcorpan@public.cloak)
# [10:09] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [10:22] * heycam|away is now known as heycam
# [10:22] * heycam is now known as heycam|away
# [10:38] * Joins: teoli (~teoli@public.cloak)
# [10:41] * Quits: {Darktears} (~darktears@public.cloak) (Client closed connection)
# [11:37] * Joins: dbaron (~dbaron@public.cloak)
# [12:42] * Joins: curvedmark (~curvedmark@public.cloak)
# [12:48] * Joins: darktears (~darktears@public.cloak)
# [13:01] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [13:14] * Joins: darktears (~darktears@public.cloak)
# [13:59] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [14:01] * Joins: teoli (~teoli@public.cloak)
# [14:02] * Joins: plh (plehegar@public.cloak)
# [14:02] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [14:25] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [14:51] * Joins: teoli (~teoli@public.cloak)
# [15:28] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:41] * Quits: curvedmark (~curvedmark@public.cloak) ("My iMac has gone to sleep. ZZZzzz…")
# [15:49] * Joins: glenn (~gadams@public.cloak)
# [15:49] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [15:49] * Joins: glenn (~gadams@public.cloak)
# [16:04] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [16:09] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:17] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:25] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:42] * Joins: tobie (tobie@public.cloak)
# [16:47] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:52] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [16:53] * Joins: cabanier (~cabanier@public.cloak)
# [16:54] * Joins: cabanier1 (~cabanier@public.cloak)
# [17:00] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 180 seconds)
# [17:10] * Joins: lmclister (~lmclister@public.cloak)
# [17:20] * Quits: cabanier1 (~cabanier@public.cloak) (Client closed connection)
# [17:29] * Joins: cabanier (~cabanier@public.cloak)
# [17:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:50] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [17:51] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:51] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:59] * Quits: abucur (~Adium@public.cloak) ("Leaving.")
# [18:01] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:02] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:05] * Joins: glenn_ (~gadams@public.cloak)
# [18:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:11] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [18:18] * Joins: cabanier (~cabanier@public.cloak)
# [18:33] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:36] * Joins: rhauck (~Adium@public.cloak)
# [18:52] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:03] * leaverou is now known as leaverou_away
# [19:16] <plinss> TabAtkins: the widlparser now supports constructors, they appear as synthetic members of interfaces
# [19:19] <SimonSapin> I read this as "wild parser"
# [19:45] <plinss> heh, I often mistype it as that...
# [19:47] <SimonSapin> maybe you should just rename it :)
# [19:48] <plinss> nah, I like the implication of 'wild parser'
# [19:51] <SimonSapin> I mean rename it to wildparser
# [19:55] * Quits: tobie (tobie@public.cloak)
# [19:57] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [19:58] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [20:04] * Quits: zcorpan_ (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [20:15] <TabAtkins> plinss: I'm planning to spend some hacking time on the airplane to do the integration. It'll be a pretty big job, I think.
# [20:20] <plinss> TabAtkins: it should be pretty straightforward, you can always refer to Shepherd's spec parser to se how I use it
# [20:21] <TabAtkins> Does it only work if there's no markup, only webidl?
# [20:21] <plinss> Yes
# [20:21] <TabAtkins> Ok, just making sure.
# [20:22] <TabAtkins> I'm planning on automatically deciding between <dfn> and <a> based on whether I can find a link target in the document or not.
# [20:22] <TabAtkins> Rather, just find a link target in the data.
# [20:23] <plinss> not sure what you mean there
# [20:24] <TabAtkins> Within the spec being generated, I plan to fill in the idl with a bunch of <dfn> or <a> markup.
# [20:24] <TabAtkins> Can't just leave it as naked text.
# [20:26] <plinss> ah, gotcha
# [20:26] <plinss> yeah, makes sense
# [20:27] <TabAtkins> I've been trying to mark up my idl fragments manually, and it ends up being *insane*.
# [20:27] <TabAtkins> *So* much cruft, it distracts from the code.
# [20:28] <plinss> I believe ReSpec does something similar
# [20:30] <plinss> are you going to put the <dfn> and <a>s around only the names of the constructs?
# [20:30] <Ms2ger> ReSpec's way of dealing with idl is horrible
# [20:31] <plinss> Ms2ger: suggestions for a better way?
# [20:31] <Ms2ger> I'm fine with the way the DOM spec does it
# [20:38] <TabAtkins> plinss: Yes.
# [20:38] <TabAtkins> Ms2ger: We're just talking about the markup in the IDL block itself, not all the crazy shit that respec generates in addition.
# [20:39] <plinss> Ok, I'm going to add a function to the parser to help with that then, it can preserve whitespace and call a callback with each construct so you can add the markup...
# [20:39] <TabAtkins> Excellent!
# [20:39] <Ms2ger> Well, people claim that respec doesn't allow them to use new idl features
# [20:39] <Ms2ger> As long as you don't do that...
# [20:39] <plinss> so you can just call parser.decorate(idlText, callback) and get the output you want...
# [20:39] <TabAtkins> Now, the *ideal* behavior would recognize <dfn> and <a> elements in the source as well, and pass them in too, so people can customize the markup when necessary.
# [20:40] <TabAtkins> plinss: Unknown things in the markup just get passed through, right? I remember people complaining about respec doing that.
# [20:41] <plinss> currently it skips over genuine syntax errors, I can preserve them in the decorate function
# [20:41] <TabAtkins> Yeah, "syntax error" is a shorthand for "errors, and new things that I'm too outdated to recognize", so preserving them would be good.
# [20:42] <plinss> k
# [20:42] <plinss> it already preserves unknown extended attributes
# [20:42] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:43] <TabAtkins> Yeah, but nonsense is still good to preserve as such.
# [20:43] <plinss> sure
# [20:49] <TabAtkins> Hm, I appear to be unable to push to dvcs. Anyone else having this problem?
# [20:49] <TabAtkins> 500 internal server error
# [20:52] * Joins: Henke37 (~Henrik@public.cloak)
# [20:54] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:54] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:55] <Henke37> so, I want to get a new module written, what should I do?
# [20:58] <TabAtkins> You've jumped ahead of yourself a few steps. ^_^
# [20:59] <TabAtkins> Send a message to www-style describing what problem you're having. Optionally, also describe some ideas you've had for solutions.
# [20:59] <Ms2ger> Make sure to split those up
# [21:00] <TabAtkins> Maybe your problems are already solved by something. Maybe they can be solved by a small tweak to an existing thing. Maybe they require a new feature in an existing module. Maybe they require a new module. Maybe your problem, sadly, isn't quite important enough to be worth adding something to the web platform to solve it, and you have to engineer around
# [21:00] <TabAtkins> it.
# [21:00] <Henke37> I did that, in februrary
# [21:01] <Henke37> http://lists.w3.org/Archives/Public/www-style/2013Feb/0501.html
# [21:01] <TabAtkins> Let's see... "Styling composite elements"?
# [21:01] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:01] <Henke37> correct
# [21:02] <TabAtkins> Everything I've said in that thread still stands. Form controls are exceedingly complex to figure out how to style, because there's no common style to them across platforms.
# [21:02] <TabAtkins> And Android has actually been getting *more* distant from desktop since last February.
# [21:02] <TabAtkins> They've got a really nice, easy-to-use calendar picker now that's dramatically different from the one that Chrome desktop has.
# [21:03] <TabAtkins> If you can come up with a good suggestion for it, feel free to suggest things. This is not something that'll happen without good, convincing work that sways the browser people. It's not something we can justify by itself.
# [21:05] <Henke37> what do you mean with "a good suggestion" exactly?
# [21:06] <TabAtkins> Something that addresses the styling needs while still allowing browsers the flexibility to change their form controls (which can be approximate today by having a solution that flexibly and cleanly handles all the existing variants of form controls across platforms).
# [21:06] <TabAtkins> For example, defining generic "theme colors" or something that browser choose how to use on their own.
# [21:09] <TabAtkins> This would give you less control than you're asking for, but might be generic enough to actually *work*.
# [21:09] <Henke37> it is never going to be possible to do sane design if the browser has freedom to do anything it feels like
# [21:09] <TabAtkins> And it's never going to be possible to innovate in form control layout if we specify exactly what the form controls look like so that authors can exercise precise control.
# [21:10] <TabAtkins> We've got two conflicting interests here.
# [21:10] <TabAtkins> On the one hand, authors. On the other hand, users and browser vendors.
# [21:10] <Henke37> "You wanted a dropdown? you get a modal dialog box with several columns!"
# [21:10] <TabAtkins> So far, the balance has consistently been on the side of "users and browser vendors", and no suggestion so far has shifted away from that.
# [21:10] <Henke37> no formal suggestion that is
# [21:11] <TabAtkins> ...yes? Those types of things are often far more usable on a mobile device with my fat fingers than the desktop equivalents are.
# [21:11] <Henke37> browsers has exposed some styling abilities in the past
# [21:11] <TabAtkins> God forbid I try to use a desktop calendar picker on mobile.
# [21:11] <TabAtkins> Yeah, and try to use those on mobile.
# [21:11] <TabAtkins> We just ignore them.
# [21:11] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:11] <TabAtkins> Because trying to obey them is nonsense.
# [21:12] <TabAtkins> Or, shudder, use a desktop time picker on mobile. That would be absolutely terrible.
# [21:12] <Henke37> hmm, what if the approatch would be limited to implementations that chose to use a certain design?
# [21:12] <TabAtkins> That doesn't help much. You presented a use-case up above (with "You wanted a...") that indicates that control over the mobile design is important too.
# [21:13] <Henke37> I beg to differ, a lot of the controls are the same everywhere
# [21:13] <TabAtkins> And a lot are dramatically different. So?
# [21:13] <Henke37> start by letting author style the common parts, toss the unstable parts to a higher level
# [21:14] <TabAtkins> That's only doable if we think there's a plan to actually reach the next level.
# [21:14] <TabAtkins> We punt only when we're pretty sure we can solve something in the future, but dont' ahve the time/energy to do it right now.
# [21:15] <TabAtkins> Without a plan to solve the rest, solving just a small corner isn't very valuable, particularly if it actually *blocks* future efforts to solve the whole thing consistently.
# [21:15] <TabAtkins> Which I'd be very afraid that what you're suggesting would do.
# [21:15] <TabAtkins> Browser devs are remarkably (and usually correctly) resistant to do something twice if it's already been solved once, even when it's horrible.
# [21:16] <Henke37> meanwhile, authors are forced to either use horrible hacks or recreate the entire control
# [21:17] <TabAtkins> Yup. Unfortunately, living with one-off JS hacks on individual sites is better than standardizing an only-slightly-less-horrible solution and forcing all browsers to implement it.
# [21:17] <TabAtkins> It sucks, but that's how it works.
# [21:17] <TabAtkins> I've thought about the issue off and on for 5 years, and haven't come up with any good answers yet.
# [21:18] <TabAtkins> Simple fact is, *most* people are perfectly okay with the stock form controls. They're not always ideal, but oh well, they're good enough, and it's not worth turning to the difficulties of JS (and the attendant drop in usability and accessibility that usually comes with it) just to make it look a little prettier.
# [21:18] <TabAtkins> Some people aren't, and I'd love to help them - they're a pretty large niche.
# [21:19] <TabAtkins> But we can't just take the obvious path, *because the obvious solution is very bad*.
# [21:20] <Henke37> I claim that some of this is already standardized. maybe not with this intent, but none the less usable for this purpose
# [21:20] <Henke37> I am talking about how people have custom submit buttons
# [21:20] <Henke37> it is wildly implemented
# [21:21] <TabAtkins> Small parts of the "obvious solution" are unofficially and inconsistently implemented across multiple browsers, yes.
# [21:21] <Henke37> I mean the parts that are already in the standards
# [21:21] <TabAtkins> There are no parts already in standards for styling form controls.
# [21:21] <TabAtkins> By the standard, form controls are "replaced elements", and CSS has nothing to do with what's inside of them.
# [21:21] <Henke37> the <input type="image"> and <button><img></button> parts of html says otherwise
# [21:22] <TabAtkins> Okay?
# [21:22] <Henke37> and so far people haven't done anything stupid with them
# [21:23] <Henke37> as far as abusing <input type="image"> just for the custom image is considered sane
# [21:24] <TabAtkins> Image buttons are rare, and buttons are among the simplest things you can possibly do. Every device I can think of deals with them in the exact same way: by showing a button.
# [21:24] <Henke37> indeed
# [21:24] <TabAtkins> If all you want to style is buttons, that's a much simpler problem, because it's a *button*.
# [21:24] <TabAtkins> For all practical purposes, it's a standard CSS box with nothing special about it.
# [21:25] <Henke37> sure, if you limit yourself to plain old run of the mill buttons
# [21:26] <Henke37> but how about the special purpose buttons? checkboxes and radio buttons
# [21:26] <TabAtkins> Those wouldn't be too much harder, but they are indeed somewhat special.
# [21:26] <TabAtkins> But still, likely doable.
# [21:27] <Henke37> then there is the file upload control
# [21:27] <TabAtkins> Same with text inputs and textareas - likely can have their styling fully standardized, because they're just boxes with text in them.
# [21:28] <Henke37> I have yet to see a single browser that has done a file upload differently than a textbox and a button
# [21:28] <TabAtkins> Android doesn't have a textbox.
# [21:28] <TabAtkins> Just a button and a message.
# [21:29] <Henke37> a message?
# [21:29] <TabAtkins> Yeah, the one I'm looking at now just says "No file chosen", but it's not a textbox that I can type anything into.
# [21:29] <TabAtkins> Dunno what it'll say if I take a picture or something.
# [21:30] <TabAtkins> Okay, it shows the auto-genned filename.
# [21:30] <TabAtkins> Still though, not actually a textbox.
# [21:31] <Henke37> people most certianly want to style this control
# [21:31] <Henke37> they sure are trying
# [21:32] <Henke37> and that is combined with people being unhappy about having to submit the form before the upload happens
# [21:32] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [21:32] <Henke37> there is a lot of effort spent on alternative upload solutions, usually involving something like flash
# [21:32] <TabAtkins> Yes, I know they want to. I keep telling you that I understand all of this: the desire to do so, and the hacks that people do today, *because I did them when I was a webdev*.
# [21:32] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:37] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [21:38] <Henke37> to summarize: can't enfore browsers to use specific controls. Would be bad to offer styling that only works for specific controls.
# [21:39] <TabAtkins> And further: some controls (particularly old pre-HTML4 ones) are probably simple and consistent enough to standardize, but newer ones aren't. Dunno if it's acceptable to expose styling for only some form controls.
# [21:39] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:41] <Henke37> do you recall if this has ever been brought up in a formal meeting?
# [21:41] * leaverou_away is now known as leaverou
# [21:44] <TabAtkins> Yes, though not seriously since I joined the group.
# [21:44] <TabAtkins> Old-timers could tell more.
# [21:45] <TabAtkins> (Though any such old discussion predate wide adoption of the new HTML input types and the rise of mobile OSes with more-usable inputs, so the only real outlier back then was <select>, sometimes.)
# [21:45] <TabAtkins> Even on older phones, though, <select> and especially <select multiple> were often crazy compared to desktops. I had a browser that would take you to a modal page which presented them as either a list of radio buttons or checkboxes.
# [21:46] <Henke37> that reminds me, was there ever any statistics for the adaptions of the new html5 input types?
# [21:46] <TabAtkins> Which was great, to be honest. Actually made me want to use <select multiple>, except I know that it would have been terrible for desktop users.
# [21:46] <TabAtkins> Probably, though I don't know what they are. I believe adoption is pretty good.
# [21:47] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [21:47] <Henke37> some have rather simple implementations
# [21:47] <Henke37> the email type in particular
# [21:48] * leaverou is now known as leaverou_away
# [21:49] <TabAtkins> Yeah, that's basically a text input, except with unique autocomplete/virtual keyboard behavior.
# [21:50] <TabAtkins> Really, the problematic things are <select> and <select multiple>, the "file" type somewhat, the "date", "time", and related types quite strongly, and the "color" type.
# [21:50] <TabAtkins> "number" to some extent - on desktop Chrome i get tiny up/down buttons, but on mobile it just gives me a numeric keyboard and otherwise looks like a plain text input.
# [21:50] <Henke37> that sounds like a complete list, for the form elements
# [21:51] <TabAtkins> Both of these are pretty bad, and I'd like a better spinner-type input for it.
# [21:53] <Henke37> hmm, whose idea was it to have a <keygen> element?
# [21:54] <TabAtkins> IE5, I think.
# [21:54] <TabAtkins> Ignore it, it's terrible and no one cares.
# [21:54] <Henke37> I have to agree there
# [21:54] <TabAtkins> Oh, and it's also Korea's fault - their dependence on IE for their banking sites led to <keygen> having non-ignorable usage for browsers.
# [21:55] <Henke37> what do you think about the meter and progress elements?
# [21:56] <Ms2ger> What, no
# [21:56] <Ms2ger> keygen is a Mozilla or Netscapeism
# [21:56] <TabAtkins> Ms2ger: Ah, hm. Ok.
# [21:56] <TabAtkins> Well, regardless, it's terrible and nobody likes it.
# [21:57] <Henke37> I would find it strange for IE to offer it when they already use a different certificate system
# [21:57] <TabAtkins> Henke37: As I said back in the Feb thread, I think those are both reasonable things to standardize somehow.
# [21:57] <Henke37> ah right! I must have missed that when I reviewed it
# [21:58] <Henke37> how are different implementations doing the ui for the video and audio elements?
# [21:59] <TabAtkins> Distinctly.
# [21:59] <Henke37> my initial message did list a long list of possible sub elements
# [22:03] * leaverou_away is now known as leaverou
# [22:12] * leaverou is now known as leaverou_away
# [22:25] * heycam|away is now known as heycam
# [22:31] <plinss> TabAtkins: do you need the widlparser to preserve any markup that may be in the idl?
# [22:31] <TabAtkins> That would be ideal, yes, so that people can manually mark up links when necessary.
# [22:31] <TabAtkins> If it's too difficult, I understand.
# [22:32] <TabAtkins> Or possibly I should get to work on providing a way to link to foreign things that aren't in Shepherd's link database.
# [22:32] <plinss> That's kind of problematic, because <foo> is valid idl
# [22:33] * leaverou_away is now known as leaverou
# [22:34] <plinss> BTW, if you need more specs in Shepherd's DB, just ask
# [22:35] <TabAtkins> But it's not valid HTML, hrm.
# [22:35] <TabAtkins> ok
# [22:35] <plinss> Well, it could be valid HTML
# [22:35] <TabAtkins> For example, I have right now "sequence<<a interface>FontFace</a>>"
# [22:37] <plinss> It doesn't eat HTML entities at the moment... I presume those are decoded on input and encoded on HTML output
# [22:37] <Henke37> is there any way for css to add html content?
# [22:38] <plinss> If you need markup in the idl, maybe we create a micro syntax that the widlparser treats as white space...
# [22:38] <plinss> Henke37: no
# [22:39] <Henke37> it would be a big mess if it was possible. it would allow for loops
# [22:39] <TabAtkins> plinss: Hm, maybe. I mean, the only markup you'd possibly need is to mark up something as a link to something else.
# [22:39] <Henke37> css is enough of a mess without bringing in infinite loops
# [22:39] <TabAtkins> A microsyntax for putting a link immediately before the token in question might work.
# [22:39] * leaverou is now known as leaverou_away
# [22:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:43] <plinss> Links like your example above can just be generated during the markup process I'm building in to the parser...
# [22:44] <TabAtkins> Yes, it can.
# [22:44] <TabAtkins> But assume it was actually a sequence of some other interface that Shepherd doesn't know about.
# [22:46] <plinss> Well, an option for that is you have a 'foreign link' table for things not Shepherd's DB
# [22:46] <plinss> Then you can auto link them everywhere else too
# [22:47] <TabAtkins> Yeah, I've got an issue about that in github.
# [22:47] <plinss> K
# [22:48] <TabAtkins> Let's assume for now that it's not necessary for you to do anything with markup.
# [22:48] <plinss> Works for me
# [22:50] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [22:56] * Joins: teoli (~teoli@public.cloak)
# [23:15] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:15] * Joins: teoli (~teoli@public.cloak)
# [23:31] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [23:43] * Joins: teoli_ (~teoli@public.cloak)
# [23:43] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:49] * heycam is now known as heycam|away
# Session Close: Fri Sep 06 00:00:00 2013

The end :)