| 00:52 | <MikeSmith> | Hixie: what can I do to convince you to add an element.createOutline() to the spec |
| 00:52 | <MikeSmith> | for generating just a static Outline object |
| 00:52 | <MikeSmith> | (I mean with not live nodes) |
| 00:55 | <othermaciej> | what is it for? |
| 01:26 | <MikeSmith> | hey othermaciej |
| 01:26 | <othermaciej> | hi MikeSmith |
| 01:27 | <MikeSmith> | element.createOutline would be for using the outline algorithm to generate and Outline that can could then be used to, say, add a TOC to a document |
| 01:28 | <MikeSmith> | the actuall adding-the-TOC part would be application-specific to the code of whatever Web application |
| 01:28 | <MikeSmith> | that is, Web authors would have to roll their own for that |
| 01:29 | <MikeSmith> | but at least they'd have a built-in native way to get the Outline to work with |
| 01:29 | <MikeSmith> | instead of N different Web authors needing to write their own implementations of the outline algorithm in their own JS |
| 02:01 | <Hixie> | MikeSmith: convince me a couple of UAs would implement it :-) |
| 02:02 | <MikeSmith> | othermaciej: please tell me and Hixie you would implement createOutline |
| 02:03 | <othermaciej> | why is dynamically creating a TOC at runtime useful? |
| 02:04 | <othermaciej> | I would tend to think doing a pass over the whole document when the page is loaded is not a great thing to do, perf-wise |
| 02:04 | <othermaciej> | better to have your document already include a TOC |
| 02:05 | <MikeSmith> | sure |
| 02:05 | <MikeSmith> | but I think the same could be said for a lot of things you can do on the client side |
| 02:05 | <othermaciej> | if you don't care for that, and somehow really need to dynamically create a TOC (maybe you are a word processing app), you can implement the Outline algorithm or similar algorithm of choice in JS |
| 02:05 | <Hixie> | othermaciej: well, the method could do it on demand |
| 02:05 | <MikeSmith> | right |
| 02:05 | <othermaciej> | perf is not a good argument to make it built in, because it's bad for perf anyway (compared to precomputing your TOC) |
| 02:06 | <othermaciej> | convenience might be an argument if there was huge demand for this specific functionality |
| 02:06 | <othermaciej> | there's nothing corresponding in popular native APIs so a priori I would assume it's not a necessary part of a good platform |
| 02:06 | <othermaciej> | but to be fair, the Web has more things that blur the lines between app and document |
| 02:07 | <Hixie> | the web is the only scriptable platform that has scripting in any serious sense, isn't it? |
| 02:07 | <Hixie> | s/scriptable/document/, sorry |
| 02:07 | <othermaciej> | I have not previously heard of demand for this particular functionality though so I can't say it would be a high priority |
| 02:09 | <MikeSmith> | yeah I guess I should try to find some JS libraries that are providing something similar already |
| 02:10 | <MikeSmith> | "TOC is a jQuery plugin that will automatically generate a table of contents for your page" |
| 02:10 | <MikeSmith> | http://projects.jga.me/toc/ |
| 02:10 | <MikeSmith> | https://github.com/jgallen23/toc |
| 02:11 | <MikeSmith> | actually it seems like there are at least half a dozen jQuery TOC plugins |
| 02:12 | <MikeSmith> | so at least for anybody actually using those already, the perf issue's already there |
| 02:13 | SamB | wonders why entirely non-normative sections get the implementation status in those boxes, instead of just bug boxes ... |
| 02:13 | <MikeSmith> | wow even a Drupal jQuery TOC plugin |
| 02:13 | <MikeSmith> | SamB: because the annotation mechanism doesn't distinguish between normative and non-normative sections |
| 02:15 | <SamB> | I suppose that is the most likely explanation, yes |
| 02:16 | <SamB> | but that leaves me wondering how some sections have opted out, which leaves me looking for my login info ... |
| 02:17 | <MikeSmith> | opted out? no sections have annotations by default |
| 02:17 | <MikeSmith> | the only way for an annotation gets added it by somebody taking time to manually add one |
| 02:20 | <JosephSilber> | How come it's 2014 and we still can't use proper HTTP verbs in HTML? |
| 02:22 | <SamB> | JosephSilber: why should HTML be using HTTP verbs in the first place? |
| 02:22 | <JosephSilber> | SamB: Don't you want to use a form to update a record? |
| 02:23 | <SamB> | do you mean verbs like BREW or somesuch? |
| 02:23 | <JosephSilber> | PUT/PATCH/DELETE |
| 02:24 | <SamB> | those are rather exotic verbs, why would you expect javascript to be trusted with them? |
| 02:24 | <JosephSilber> | SamB: JavaScript already is. Was talking about HTML. |
| 02:31 | <Hixie> | HTTP verbs are so last century |
| 02:31 | <JosephSilber> | Can't tell whether you're serious. |
| 02:32 | <JosephSilber> | Hixie: sarcasm doen't come across well in writing. |
| 02:33 | <Hixie> | more seriously, HTTP should just have two verbs, GET and POST. Endpoints should be scripts. URIs for APIs, not resources. |
| 02:33 | <Hixie> | resources are too abstract to be given URLs in a practical world. |
| 02:34 | <JosephSilber> | Hixie: So I take it you aren't a fan of the RESTful mindset? |
| 02:35 | <Hixie> | you could say that. |
| 02:35 | <Hixie> | REST has caused thousands of web authors to waste time on a dead-end idea. |
| 02:36 | <JosephSilber> | Then what's the difference between GET and POST. |
| 02:36 | <JosephSilber> | caching? |
| 02:36 | <JosephSilber> | bigger payload? |
| 02:36 | <SamB> | Hixie: I kind of think HEAD is useful too |
| 02:38 | <zewt> | the APIs i design tend to be a single URL (let "URI" die already, everything's a URL), posted JSON, with the whole body of the command in the JSON |
| 02:38 | <Hixie> | JosephSilber: GET is idempotent and thus (more) cachable. |
| 02:38 | <SamB> | zewt: there ARE a few URNs in use |
| 02:38 | <Hixie> | SamB: HEAD, in practice, too often returns bogus data to be valid. |
| 02:38 | <SamB> | they work pretty well for namespace URIs |
| 02:38 | <JosephSilber> | Can we at least get POST on anchor tags? |
| 02:38 | <zewt> | puts the whole body of the request in a single vocabulary (a JSON dictionary), which is so much simpler than some of it being in a request body, some of it in the URL, some of it in the HTTP request type... |
| 02:39 | <zewt> | Hixie: i've had webkit in iOS cache POST :( |
| 02:39 | <zewt> | "surprise!" |
| 02:39 | SamB | would love an ISBN URL scheme |
| 02:39 | <Hixie> | JosephSilber: POST is an action, links are supposed to be safe to click. |
| 02:40 | <Hixie> | JosephSilber: another way of describing GET and POST is GET is a link, POST is a button. |
| 02:40 | <JosephSilber> | Hixie: theoretically, but in practice you can style it however you like. |
| 02:40 | <JosephSilber> | e.g. a delete button shouldn't need a hidden form behind it. |
| 02:40 | <Hixie> | well sure, you can also make a link look like a text field... |
| 02:40 | <Hixie> | buttons don't need <form>s anymore |
| 02:41 | <JosephSilber> | How would you delete a record without a form (and no js) |
| 02:41 | <JosephSilber> | ? |
| 02:41 | <zewt> | Hixie: well, ever since it's been possible to attach scripts to clicking things that look like links, that's sort of gone out the window |
| 02:42 | <zewt> | (not that "looks like a link" itself means much these days; google search is apparently removing the link styling from result headers, which drives me nuts) |
| 02:43 | <SamB> | google has a lot of nerve making bad changes as well as good changes ;-P |
| 02:43 | <Hixie> | JosephSilber: <button formaction="delete?record=foo" formmethod"POST" ...> |
| 02:43 | <zewt> | JosephSilber: idempotence is part of it, but I think equally or maybe more important is that POST has a request body (which means you can't copy-link-location and everything surrounding with that) and GET doesn't |
| 02:43 | <Hixie> | if i remember the attribute names correctly |
| 02:44 | <JosephSilber> | Hixie: hmmmm... Bever seen that before. Where's it supported? Where's it documented? |
| 02:44 | <JosephSilber> | never* |
| 02:45 | <SamB> | Hixie: are you sure that's not cheating? |
| 02:45 | <zewt> | (the fact that "has a request body or not" and "is idempotent or not" are both major differences between GET and POST, despite the two being totally orthogonal, is one of those things that make me groan at HTTP) |
| 02:46 | <Hixie> | JosephSilber: http://whatwg.org/html/association-of-controls-and-forms.html#form-submission-0 |
| 02:46 | <Hixie> | JosephSilber: haven't tested it recently to see if anyone implements it |
| 02:46 | <Hixie> | SamB: cheating? |
| 02:47 | <SamB> | well, I mean, not that I haven't seen forms before that split stuff between the query parameter and the POST body ... |
| 02:47 | <JosephSilber> | While we're at it, is there any way to prevent a bob-submit buttion from sumbitting a form, without js? |
| 02:47 | <zewt> | who's bob |
| 02:47 | <JosephSilber> | non-submit* |
| 02:47 | <JosephSilber> | heh |
| 02:48 | <zewt> | poor bob :( |
| 02:48 | <JosephSilber> | I really wish I could type :( |
| 02:48 | <zewt> | if you have a submit button doing something other than submitting the form, don't you need JS to do that other action anyway? |
| 02:48 | <Hixie> | JosephSilber: (correction to what i said earlier -- you do actually need a <form> element somewhere, either in the hierarchy, or pointed to from a form="" attribute on the <button>. But that form doesn't need any fields.) |
| 02:48 | <Hixie> | JosephSilber: does seem to work in chrome, at least |
| 02:49 | <zewt> | i wonder if the "hidden submit button" catastrophe has improved since i looked at it last |
| 02:49 | <Hixie> | JosephSilber: (and the form doesn't need action="" or method="") |
| 02:49 | <Hixie> | JosephSilber: non-submit buttons don't ever submit forms, do they? |
| 02:49 | <JosephSilber> | Which brings me back to my original question: why can't we just get method=POST on an anchor? |
| 02:49 | <zewt> | where implicit submit behavior depends on whether submit inputs are hidden and how many of them there are |
| 02:49 | <Hixie> | JosephSilber: because links are for GET, we went through this |
| 02:50 | <JosephSilber> | Hixie: correct me if I'm wrong, but iirc any <button> in a form submits it. |
| 02:50 | <Hixie> | pretty sure you're wrong :-) |
| 02:50 | <JosephSilber> | "links are for GET" is really a pre-css mentality. |
| 02:50 | <zewt> | JosephSilber: i don't think having POST on an anchor makes sense, because clicking an anchor (assuming no script) means you navigate to that URL, and a POST resource needs more data than just a URL (the request body) |
| 02:51 | <JosephSilber> | zewt: You can pass those in the query string. What I'm really after is delete though, which doesn't need a payload. |
| 02:51 | <zewt> | not following; pass the POST data in the query string? |
| 02:51 | <Hixie> | JosephSilber: Yes, it is a pre-CSS mentality... CSS is optional. We shouldn't be designing HTML to do things that only make sense with CSS |
| 02:52 | <Hixie> | zewt: the example i gave above didn't have a useful body, all the data was in the submit url |
| 02:52 | <zewt> | you can pass data for a POST in the query string (like any other request), but in my mind (at least) the thing that differentiates POST from GET is the request body |
| 02:53 | <Hixie> | if you want it in a request body you'd have to do: <form id="empty-form"></form> <button type=submit formaction="delete" formmethod=POST name=record value=1987414>Delete</button> |
| 02:53 | <Hixie> | oops, missed an attribute |
| 02:53 | <Hixie> | <form id="empty-form"></form> <button type=submit form="empty-form" formaction="delete" formmethod=POST name=record value=1987414>Delete</button> |
| 02:54 | <JosephSilber> | Hixie: http://jsfiddle.net/k3nvR/ |
| 02:54 | <Hixie> | JosephSilber: that has type=submit |
| 02:54 | <Hixie> | JosephSilber: you want it to be type=button to not submit |
| 02:55 | <JosephSilber> | Oh. So it defaults to submit. |
| 02:55 | <Hixie> | (see http://whatwg.org/html#attr-button-type ) |
| 02:55 | <JosephSilber> | that settles it. |
| 02:56 | <JosephSilber> | Why do we need an empty form around the button? |
| 02:56 | <Hixie> | doesn't have to be around, you can point to it using form="". but there has to be one, because form submission is actually done by the <form>, not the <button>. |
| 02:57 | <Hixie> | so if you don't have one, the type=submit button looks for a form to submit, and comes up empty, and just gives up. |
| 02:57 | <Hixie> | (or to put it another way... form submission involves firing a 'submit' event at a form. but if there's no form...) |
| 02:58 | <JosephSilber> | I get that it's designed that way. The question is why? Seems like an implementation detail leaking into the api. |
| 02:58 | <Hixie> | it is |
| 02:58 | <Hixie> | :-) |
| 02:59 | <JosephSilber> | I'd go for :( |
| 02:59 | <Hixie> | before, <form> was where the action="" and method="" attributes had to be |
| 02:59 | <Hixie> | much later, at which point we were quite heavily constrained, we tried to add the ability for buttons to control those |
| 03:00 | <Hixie> | and we did that by just making the <Form>'s algorithm check the submit <button> element's attributes |
| 03:01 | <JosephSilber> | I guess you settle for what you get. |
| 03:01 | <JosephSilber> | Thanks :) |
| 03:01 | <zewt> | common theme of the web |
| 03:01 | <Hixie> | yeah... see /topic :-/ |
| 03:17 | <MikeSmith> | Hixie: just fyi http://patches.freeiz.com/alpine/release/index.html see the part about "Experimental extended support of recognition of UTF-8 in urls based on information from http://url.spec.whatwg.org"; |
| 03:17 | <MikeSmith> | kind of cool to see that mention of the URL standard there, of all places |
| 04:19 | <Hixie> | nice |
| 05:29 | <GPHemsley> | Hixie: Shouldn't the events specified by DOM Events be listed in the Events index? |
| 05:32 | <GPHemsley> | (There should be a single place to go to to find possible values for X in 'onX') |
| 05:52 | SamB | suddenly groans at http://resources.whatwg.org/logo-xhr.svg ... |
| 07:13 | <ondras> | re |
| 07:13 | <ondras> | http://jsfiddle.net/MAeLA/ |
| 07:13 | <ondras> | gives "true" in firefox |
| 07:13 | <ondras> | is that correct? |
| 07:13 | <ondras> | (gives "false" after being appended to the document) |
| 08:36 | <Ms2ger> | ondras, interesting |
| 08:36 | <Ms2ger> | Could you file a bug on Fx? |
| 08:47 | <ondras> | Ms2ger: I found that already reported (and voted for that bug) |
| 08:48 | <Ms2ger> | Number? |
| 08:48 | <ondras> | sec |
| 08:49 | <ondras> | https://bugzilla.mozilla.org/show_bug.cgi?id=951887 |
| 09:04 | <Ms2ger> | Thanks |
| 11:04 | <mike5w3c1> | 🍺 |
| 11:04 | <mike5w3c1> | so tmux displays beer correctly |
| 11:04 | <mike5w3c1> | unlike screen |
| 11:04 | <mike5w3c1> | tmux wins |
| 11:08 | <ondras> | hm |
| 11:08 | <ondras> | no beer here in my tmux |
| 11:08 | <ondras> | due to the missing glyph, I suppose |
| 11:08 | <ondras> | 'cause I see a rectangular box with "01f37a" in it |
| 11:09 | <mike5w3c1> | ondras: oh OK |
| 11:10 | <mike5w3c1> | will I see the glyph as expected in tmux but not in screen |
| 11:10 | <mike5w3c1> | screen has other unicode shortcomings |
| 11:10 | <mike5w3c1> | so that alone is a good enough reason to switch I guess |
| 11:10 | <mike5w3c1> | for me at least |
| 11:10 | ondras | +1 |
| 11:19 | <jgraham> | Anyone want to do a super-quick review? https://critic.hoppipolla.co.uk/r/926 |
| 11:19 | <MikeSmith> | jgraham: I will try |
| 11:22 | <MikeSmith> | jgraham: r+ from me at least |
| 11:23 | <MikeSmith> | if that's good enough for you I can do the thing in critic to resolve it |
| 11:33 | <arminrosu> | hello all |
| 11:34 | <jgraham> | MikeSmith: Good enough for me |
| 11:34 | <arminrosu> | is this the right "forum" to talk about an idea regarding html |
| 11:34 | <arminrosu> | ? |
| 11:34 | <jgraham> | arminrosu: Yes |
| 11:34 | <arminrosu> | jgraham: thanks |
| 11:35 | <arminrosu> | here's a frequent issue of mine (with a proposed solution afterwards): |
| 11:35 | <arminrosu> | vector backgrounds and sprites |
| 11:35 | <arminrosu> | specifically, having a vector icon, which needs to change color |
| 11:36 | <arminrosu> | currently i use fonticons for that, but it only works for monochrome icons |
| 11:36 | <gsnedders> | How does SVG not fulfil this? |
| 11:36 | <arminrosu> | it does, i want an extension |
| 11:36 | <arminrosu> | it's a 3-step issue |
| 11:37 | <arminrosu> | i might be wrong (i hope) |
| 11:37 | <arminrosu> | so, fonticons are cool, don't work if you want it as a background style |
| 11:38 | <arminrosu> | setting a svg as background, removes my ability to change the color (fill, stroke properties) |
| 11:38 | <arminrosu> | this is an issue for me, since i need to create an element for the sole purpose of style |
| 11:38 | <arminrosu> | (shocker, right?!) |
| 11:39 | <arminrosu> | so here's my idea: assets |
| 11:39 | <arminrosu> | i would define a list of assets in e.g. the head |
| 11:39 | <arminrosu> | these could be links or inline svg or data-uri |
| 11:40 | <arminrosu> | and I would just reference them like <img src="@asset(logo)" /> |
| 11:40 | <arminrosu> | let's say logo is an inline svg |
| 11:41 | <arminrosu> | i would be able to do this in css: #logo {fill: red}, #logo:hover {fill: blue} |
| 11:41 | <arminrosu> | ^ #logo would be an asset ID |
| 11:41 | <gsnedders> | (Before you continue, I'll make mention that it's more important to communicate your problem clearly than your idea of a solution; an understanding of the problem is needed to evaluate possible solutions, yours included) |
| 11:41 | <arminrosu> | i'm done with my point :) |
| 11:42 | <arminrosu> | my problem was with not being able to style svg once they are set as a background |
| 11:42 | <gsnedders> | So the problem, if I understand it correctly, is that backgrounds are static? |
| 11:42 | <arminrosu> | yup |
| 11:42 | <arminrosu> | my thinking is, background-size is a property which arrived from this need |
| 11:43 | <arminrosu> | similarly, think of using sprites as backgrounds |
| 11:43 | <gsnedders> | Are we interested in pseudo-selectors like :hover, or general self initiated animations (imagine a spinning cube, say)? |
| 11:44 | <arminrosu> | my issue is strictly with pseudo-selectors |
| 11:45 | <arminrosu> | regarding manipulating background-image properties |
| 11:46 | <arminrosu> | and sprites, sometimes I would like to be able to say, take x,y,w,h from a sprite (which is solved by image fragments) |
| 12:00 | <arminrosu> | here is an article by nicholas galagher detailing further needs to manipulate background images, solved using pseudo elements |
| 12:00 | <arminrosu> | http://nicolasgallagher.com/css-background-image-hacks/ |
| 12:21 | <arminrosu> | gsnedders: what do you think? |
| 12:52 | <gsnedders> | arminrosu: I'm otherwise occupied at the moment; note there's been plenty of discussions about interactivity of backgrounds before. |
| 17:15 | <MikeSmith> | foolip: thanks very much for the review |
| 17:15 | <MikeSmith> | and for solving the endOfStream() mystery |
| 19:30 | <Hixie> | GPHemsley: maybe? |
| 20:18 | <Hixie> | i really would love input from some other people on the autofill fields thread |
| 20:19 | <Hixie> | which of the proposals makes most sense to you? |
| 20:19 | <Hixie> | are there any others we're missing? |
| 22:21 | <KevinMarks_> | 1 in 9 americans thinks HTML is a sexually transmitted disease: http://www.latimes.com/business/technology/la-fi-tn-1-10-americans-html-std-study-finds-20140304,0,1188415.story |
| 22:24 | <jensnockert_> | I'm not convinced that it isn't a sexually transmitted disease. |
| 22:36 | <nessy> | intercourse between WHATWG and W3C ??? |
| 22:38 | <TabAtkins> | jensnockert_: That assumes people who use HTML have sex. ^_^ |
| 22:39 | <jensnockert_> | How would it otherwise spread? |
| 22:39 | <jensnockert_> | Dirty needles? |
| 22:40 | <TabAtkins> | Seems reasonable, yeah. |
| 22:40 | <jensnockert_> | Hm… that would make sense, cutting yourself on JS is too easy these days. |
| 23:05 | <Hixie> | KevinMarks_: given the other examples on that page, that's actually a really low percentage |
| 23:36 | SamB | would have thought JPEG more likely as a sexually transmitted disease ... |
| 23:37 | <jensnockert_> | ECMAscript sounds like a skin disease. |
