| 00:03 | <hober> | tantek: see also http://www.soxaholix.com/ |
| 00:04 | <tantek> | hober do you like their markup? |
| 00:07 | <hober> | no |
| 00:07 | <tantek> | yeah |
| 00:08 | <tantek> | btw - just found this - http://xkcdexplainedexplainedexplained.tumblr.com/ |
| 00:09 | <tantek> | so here's a good example |
| 00:09 | <tantek> | http://xkcd.com/386/ |
| 00:09 | <tantek> | since the people speaking don't have explicit identities, I'm wondering what the right way to markup their dialog is |
| 00:11 | <Hixie> | <p>"Are you coming to bed?"</p> <p>"I can't. This is important."</p> <p>"What?"</p> <p>"Someone is <em>wrong</em> on the Internet."</p> |
| 00:11 | <Hixie> | ok, time to be afk again. bbl. |
| 00:11 | tantek | looks for his CMOS |
| 00:12 | <tantek> | anyway I'm thinking <object> tag with all the fallback inside |
| 00:15 | <tantek> | ah, pronouns. right. |
| 00:28 | <GPHemsley> | Oh, nice. My MIME type testing just crashed Aurora |
| 00:29 | <GPHemsley> | that is *definitely* a spec violation |
| 00:52 | <GPHemsley> | well, at least it's reproduceable |
| 04:04 | <tantek> | Hixie - CMOS agrees with you! |
| 04:04 | <a-ja> | heycam: ping |
| 04:04 | <heycam> | a-ja, pong |
| 04:05 | <a-ja> | heycam: <details> and <summary> have a chance at making esr24 release? or other priorities higher? |
| 04:06 | <tantek> | 15th edition, 11.43 Speech, Dialogue, And Conversation / Direct discourse |
| 04:06 | <tantek> | "change in speaker is usually indicated by a new paragraph" |
| 04:06 | <heycam> | a-ja, unfortunately other things have been having priority recently. next chance to look at it is probably from june 24. |
| 04:08 | <a-ja> | heycam: k....likely not then, i guess. oh well |
| 04:08 | <heycam> | a-ja, yep. sorry about that! |
| 04:09 | <a-ja> | heycam: n/p....just like to know for planning purposes. |
| 04:10 | <Hixie> | tantek: well duh :-P |
| 04:21 | <tantek> | Hixie - I like to do my homework :) |
| 04:24 | <Hixie> | :-) |
| 05:30 | <TabAtkins> | heycam: While we're on the subject of you having other things to look at, seen my email from earlier today about adding a way to declare an interface map-like? |
| 05:30 | <heycam> | TabAtkins, no, I haven't seen that yet |
| 05:30 | <heycam> | TabAtkins, what was the outcome of the thread on es-discuss? |
| 05:31 | <TabAtkins> | They don't want to add anything to ES for it, but Tom gave a quite decent suggestion of how to achieve what we want with only a little bit of help from WebIDL. |
| 05:31 | <heycam> | TabAtkins, oh, great |
| 05:31 | <TabAtkins> | His idea could be adopted by ES as well without the troubles that my other suggestions had, but I'd prefer not to wait for it. |
| 05:32 | <heycam> | TabAtkins, do you have a link so I can take a quick peek now? |
| 05:32 | <TabAtkins> | My thread? |
| 05:32 | <heycam> | TabAtkins, no the "my email from earlier today" |
| 05:32 | <TabAtkins> | http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0805.html |
| 05:34 | <heycam> | TabAtkins, so they key I guess is not to use Map.prototype's actual methods, but just to have a new set of identically named ones that do the custom behaviour? |
| 05:34 | <heycam> | *the |
| 05:35 | <TabAtkins> | Yes, basically. And have the set of them maintained in WebIDL rather than individual specs, so one update will fix every spec. |
| 05:37 | <TabAtkins> | Kinda sad that that means Map.prototype.set.call() won't be hooked and work correctly (it'll just throw instead, I think, as the object doesn't have a [[MapData]] internal property), but whatever, that's the only real downside left. |
| 05:37 | <heycam> | TabAtkins, mmm. if you cannot do arbitrary map insertions/removals without side effects, then it's kind of not a Map as defined by ES anyway |
| 05:38 | <TabAtkins> | omg, not this again. Yes, it's a Map in every way. ES happened to define that the thing named by Map is specifically an object->object map, but that shouldn't prevent other types of maps from existing or interoperating. Maps are naturally parametric. |
| 05:39 | <heycam> | ("it depends what you mean by Map") |
| 05:39 | <TabAtkins> | That's why I lower-cased when allowed by English conventions. ^_^ |
| 05:39 | <heycam> | ok :) |
| 05:39 | <TabAtkins> | A map is a list of key/value tuples. A Map is the ES class, which is defined as object->object. |
| 05:40 | <heycam> | ok, sure. |
| 05:40 | <TabAtkins> | A CSSVariablesDeclaration is a map which is string->string, and which is backed by a CSSStyleRule object. |
| 05:41 | <heycam> | anyway, I'll take a stab at it a bit after I get back from F2F stuff next week |
| 05:41 | <TabAtkins> | Cool. See you in Tokyo! |
| 05:41 | <heycam> | see you then |
| 06:48 | <tantek> | Hixie - long form alt text (including aforementioned dialog) for an image posted as normal inline markup inside an object: http://tantek.com/2013/149/b1/bayesian |
| 07:03 | <jgraham> | tantek: I'm rather sure the W3C access change at Opera was intentional. I remember mail from Charles. |
| 07:04 | <wilhelm> | tantek: I did a similar experiment here: http://wja.no/t/comic/ . (Stolen graphics with no attribution; previously not linked from anywhere.) |
| 07:04 | <tantek> | jgraham. huh - interesting. wonder when that happened. |
| 07:05 | <tantek> | wilhelm - interesting experiment! yes it looks like you used XKCD as a source. |
| 07:05 | <wilhelm> | If you have 12 panels, the comic will work on any screen resolution. |
| 07:05 | <wilhelm> | Four columns, tree, two, one. |
| 07:05 | <tantek> | my workflow happened in a different order, I was inspired to draw the comic first, and then was encouraged to post it, and then had to of course figure out the markup to do so. |
| 07:06 | <tantek> | interestingly enough, at least some aggregators use the fall back markup instead of the <object>! e.g. http://planet.mozilla.org/ |
| 07:07 | <wilhelm> | Yeah, my experiment started with "how can you make a digital graphic novel work on any screen size". I also found a way to use panels of different sizes. |
| 07:08 | <wilhelm> | Would be fun to try with some real content. |
| 07:13 | <Ms2ger> | http://quotes.burntelectrons.org/6945 |
| 07:15 | <tantek> | Ms2ger - almost a haiki |
| 07:15 | <tantek> | haiku even |
| 07:25 | <Ms2ger> | http://i.imgur.com/CwjA7Z1.jpg |
| 07:36 | <zcorpan> | i wonder what's wrong with <h1>heading<br>subheading</h1> |
| 07:38 | <Ms2ger> | Styling |
| 07:39 | <zcorpan> | <h1><span>heading</span><br><span>subheading</span></h1> |
| 07:48 | <nessy> | I think it's about automatically creating a table-of-contents thing |
| 07:48 | <nessy> | you don't really want the subheading in it |
| 07:49 | <nessy> | just my 2c worth though ;-) |
| 08:13 | <SteveF> | zcorpan: thats one of the options suggested in the spec (except for the <br>) display:block is used instead, but use of <br> should also be shown http://www.w3.org/html/wg/drafts/html/master/common-idioms.html#sub-head |
| 08:14 | <zcorpan> | SteveF: the <br> seems relevant if it's supposed to be understandable without css |
| 08:15 | <zcorpan> | running together two sentences can change the meaning |
| 08:17 | <SteveF> | zcorpan: bug filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=22204 yeah agree either that or delineation such as : or - much discussion here http://html5doctor.com/howto-subheadings/ |
| 08:19 | <zcorpan> | SteveF: in the "Ramones -" example, how is the dash hidden? |
| 08:20 | <SteveF> | CSS display:none guess i need anther bug filed... |
| 08:22 | <SteveF> | so it could be <i>-</i> i {display:none} |
| 08:24 | <zcorpan> | isn't that abuse of <i>? |
| 08:27 | <SteveF> | don't think so "The i element represents a span of text in an alternate voice or mood" it would make sense to differentiate the - as something other than the rest of the text and what does abuse of <i> actually mean who does the abuse effect? |
| 08:29 | <SteveF> | zcorpan: you can comment on bug if you think its an issue https://www.w3.org/Bugs/Public/show_bug.cgi?id=22205 |
| 08:31 | <annevk> | zcorpan: fyi, @namespace has similar issues as @charset |
| 08:44 | <zcorpan> | annevk: what issues? |
| 08:45 | zcorpan | wonders why the attributes are readonly |
| 08:46 | <annevk> | zcorpan: you can't do modifications to namespace declarations or insert new ones as that breaks parsed selectors |
| 08:46 | <annevk> | zcorpan: what you actually want to do is expose a readonly namespace map |
| 08:46 | <annevk> | zcorpan: there's some emails about that |
| 08:47 | <annevk> | zcorpan: there's also some emails about that prolly not being possible due to legacy |
| 08:47 | <zcorpan> | ok, haven't read those |
| 08:50 | <zcorpan> | should all readonly attribute CSSStyleDeclaration style; have [PutForwards=cssText] ? |
| 08:51 | <SimonSapin> | One of the reasons I dropped cssutils and wrote tinycss: when I ask cssutils for the selector of a style rule, it serializes it from its internal representation which uses namespace URLs rather than prefixes. To do that, it loops over every rule of the stylesheet to rebuild the prefix map, just in case you’ve messed with @namespace rules. |
| 08:51 | <SimonSapin> | Net result: O(n²) time for getting all selectors from a stylesheet with n style rules. |
| 08:51 | <annevk> | zcorpan: depends on your school of thought it seems |
| 08:51 | <annevk> | zcorpan: I think it's useful |
| 08:55 | <heycam> | annevk, I wonder if while you're with alex, wycats, etc. you could discuss named getters/setters |
| 08:55 | <heycam> | annevk, seems some people don't really like them (sicking, at least), while others do |
| 08:55 | <annevk> | heycam: nobody wants them |
| 08:55 | <heycam> | annevk, I thought Hixie did |
| 08:56 | <annevk> | heycam: okay, almost nobody |
| 08:56 | <heycam> | :) |
| 08:56 | <heycam> | ok, I'll factor that in |
| 08:56 | <annevk> | heycam: that's why Map and such exists |
| 08:56 | <heycam> | right |
| 08:56 | <heycam> | that's what made me think of it again |
| 08:56 | <annevk> | heycam: btw, you should talk with wycats__ about JSIDL <> Web IDL |
| 08:57 | <wycats__> | heycam |
| 08:57 | <wycats__> | hey |
| 08:57 | <annevk> | heycam: he thinks morphing Web IDL might be more effort |
| 08:57 | <heycam> | hi wycats__ |
| 08:57 | <annevk> | ah |
| 08:57 | <annevk> | there he is :) |
| 09:16 | <SteveF> | GPHemsley: JonathanNeal notes, ideas on stuff after discussion last night http://lists.w3.org/Archives/Public/public-html/2013May/0173.html |
| 09:48 | <zcorpan> | annevk: http://lists.w3.org/Archives/Public/www-style/2009Oct/0181.html ? |
| 09:48 | <annevk> | zcorpan: looks accurate |
| 09:48 | <annevk> | zcorpan: man that was long ago |
| 09:48 | <zcorpan> | yeah |
| 09:49 | <zcorpan> | i haven't found anything about "prolly not being possible due to legacy" |
| 10:06 | <zcorpan> | insertRule('@namespace "foo"', 0) throws in webkit/blink |
| 10:07 | <zcorpan> | and presto |
| 10:11 | <zcorpan> | though gecko and ie10 allow it, but don't invalidate the style sheet if it's being added after other things |
| 11:03 | <annevk> | darobin: is the github.com/w3c stuff synced on w3.org somehow? |
| 11:04 | <darobin> | annevk: not yet, but the systeam is working on making that generic |
| 11:04 | <annevk> | darobin: k |
| 11:04 | <darobin> | you don't have to decide now, you can use your organisation and move the repos later if it makes sense |
| 11:04 | <annevk> | darobin: so w3.org will get git hosting? |
| 11:04 | <darobin> | annevk: it's definitely being looked at, yes |
| 11:05 | <darobin> | at the very least it'll get sync from github |
| 11:05 | <annevk> | darobin: kinda makes sense for the W3C TAG to be its own organization |
| 11:05 | <annevk> | darobin: so if they could consider syncing both /w3c and /w3ctag ... |
| 11:05 | <darobin> | annevk: yeah, I don't have a strong opinion on that, I just wanted to point out that you can use the w3c org |
| 11:06 | <darobin> | I can easily set you up, and grant admin over repos and stuff |
| 11:06 | <annevk> | too much management and coordination I guess, hmm |
| 11:07 | <annevk> | but anyway, sounds good about git syncing |
| 11:08 | <darobin> | as you prefer, I really don't have a preference, just know that it's on the table |
| 12:14 | <hallvors> | annevk: what did you mean by "leaving new features to the API for Fetch"? |
| 12:14 | <hallvors> | is the Fetch spec going to define what properties an XHR instance has?? |
| 12:23 | Ms2ger | wonders if dap counts as web-platform |
| 12:24 | jgraham | concurs with Ms2ger's wondering |
| 12:29 | <annevk> | hallvors: Fetch is going to define something like Response = fetch(Request) |
| 12:29 | <annevk> | euh, prolly Future<Response> |
| 12:30 | hallvors | can now prove that jgraham and Ms2ger are wonderful people, full of wondering |
| 12:31 | <hallvors> | annevk: and..? Fetch will then define properties on Request and XHR will just say "look at Fetch"? |
| 12:32 | <annevk> | hallvors: XHR will no longer be needed |
| 12:33 | <annevk> | Ms2ger: depends on the API? |
| 12:34 | <hallvors> | Oh well. I thought Fetch was about the slightly lower-level networking and XHR would still exist but defer to Fetch a lot regarding details |
| 12:35 | <annevk> | yes that too |
| 12:35 | <annevk> | that's plan a) |
| 12:35 | <annevk> | or plan 1) |
| 12:35 | <annevk> | plan 2 is to add a better API |
| 12:35 | <hallvors> | Does that mean you're basically "abandoning" the XHR spec at this point because Fetch will obsolete it anyway? |
| 12:35 | <annevk> | not sure what you mean by abandone |
| 12:35 | <annevk> | seems pretty important to define it |
| 12:36 | <hallvors> | Sorry . I'm not sure how you are planning to put the bits together |
| 12:37 | <hallvors> | if I suggest a new property for XHR instances and you say you'll "leave new features of the API for Fetch" it sounds like xhr.credentialsPolicy will be defined in the Fetch spec |
| 12:38 | <annevk> | right |
| 12:38 | <hallvors> | (even when it's proposed as an XHR property that's going to map well on to what's already in Fetch) |
| 12:38 | <hallvors> | so it sounds like you're not going to write anything in the XHR spec |
| 12:38 | <annevk> | I don't think we should extend XHR further if we're also going to do a new API soonish |
| 12:39 | <annevk> | doesn't mean we should no longer maintain XHR |
| 12:39 | <hallvors> | so that's why I'm asking if you're "abandoning" the spec |
| 12:39 | <hallvors> | in the expectation that it will be obsolete |
| 12:39 | <annevk> | what does obsolete mean? |
| 12:40 | <hallvors> | what does maintain mean? ,-) |
| 12:42 | <hallvors> | So Fetch will create a new, competing, JS-exposed API for HTTP. var req=new Request(); response = fetch(req); response.then() .. ? |
| 12:42 | <hallvors> | (or whatever your preferred futures syntax is) |
| 12:43 | <jgraham> | Why would fetch have an API? |
| 12:43 | hallvors | knows futures is considered cool but doesn't study the details of all those discussions yet |
| 12:43 | <annevk> | hallvors: yeah |
| 12:43 | <jgraham> | Shouldn't the API be a layer on top of fetch? |
| 12:43 | <annevk> | jgraham: sure |
| 12:44 | <hallvors> | jgraham: I'm just trying to understand what Anne is saying :-p |
| 12:44 | <annevk> | jgraham: "Fetch" is the model, fetch() is the API |
| 12:44 | <annevk> | (prolly, requires some further thinking) |
| 12:44 | <hallvors> | why? |
| 12:44 | <hallvors> | to use futures? |
| 12:44 | <jgraham> | annevk: Re:DAP, battery, vibration, ambient light and proximity so far |
| 12:44 | <annevk> | hallvors: yeah |
| 12:45 | <annevk> | jgraham: those seem like relevant things, although the APIs are suckish |
| 12:45 | <annevk> | hallvors: futures, and provide a way to expose a tainted response somehow |
| 12:46 | <Ms2ger> | Clearly TC39 should review them |
| 12:46 | <annevk> | Ms2ger, tears were shed |
| 12:47 | <jgraham> | Well they are things. Not obvious they are ever going to be web-exposed though |
| 12:47 | <Ms2ger> | "DAP: They Make Things" |
| 12:48 | <annevk> | jgraham: I guess I should write some tests for B2G, but I thought most were |
| 12:48 | <jgraham> | You can cause the phone to vibrate from a web page? |
| 12:48 | <Ms2ger> | *app |
| 12:48 | <hallvors> | appsite ? |
| 12:48 | <jgraham> | Well I don't know what a web app is |
| 12:49 | <jgraham> | Everyone means something different whan they say that |
| 12:49 | <annevk> | jgraham: I was hoping you could |
| 12:50 | <annevk> | jgraham: https://wiki.mozilla.org/WebAPI suggests it is |
| 12:52 | <jgraham> | Hmm, maybe then |
| 12:52 | <jgraham> | The spec doesn't say anything about permissions I guess |
| 12:52 | <jgraham> | Seems a bit obnoxious |
| 12:53 | <jgraham> | Although probably no more than the rest of the web |
| 12:59 | <annevk> | I have a test, but getting my phone on the network is hard :/ |
| 12:59 | <annevk> | http://dump.testsuite.org/vibrate/test.html |
| 12:59 | <annevk> | "test" |
| 12:59 | <Ms2ger> | It didn't |
| 13:00 | <annevk> | Ms2ger: using? |
| 13:00 | <Ms2ger> | Maybe because I don't have a smartphone and I loaded the page on my laptop |
| 13:00 | <annevk> | Ms2ger: don't you have something useful to do? :p |
| 13:01 | <Ms2ger> | http://xkcd.com/303/ |
| 13:02 | <annevk> | even reasonably matches the HTTP status code |
| 13:12 | <annevk> | hallvors: my apologies btw for not communicating much about the Fetch plan, it's still evolving, also based on input from others |
| 13:15 | <hallvors> | annevk: apology accepted (although I'm wondering if you're reluctant to add stuff to XHR to make your new API a stronger contender in comparison :-p ;-)) |
| 13:20 | <annevk> | hallvors: I'm reluctant to add stuff to avoid needless web platform complexity |
| 13:20 | <annevk> | hallvors: I'm always reluctant to add stuff |
| 13:21 | <hallvors> | he said and added a new API ;-) |
| 13:21 | <annevk> | heh |
| 13:21 | <hallvors> | (I agree with the sentiment, BTW) |
| 13:22 | <hallvors> | (this whole anti-anonymous effort was of course an attempt at simplifying things) |
| 13:23 | <hallvors> | hm.. saying I'm involved in anti-anonymous efforts in a public chatroom seems uncautious. could be misunderstood ;-) |
| 13:26 | <hallvors> | anyway. I was pushing for a tri-state withCredentials because it seems simpler, Sicking had some good and valid concerns and while I think the mess would be temporary and the improvement permanent, I'm happy to defer to his experience and implementor skillz. Especially if you actually give me a tri-state property eventually :-) |
| 13:26 | <annevk> | most things in #whatwg are misunderstood, though only by people who want to |
| 13:26 | <hallvors> | heh |
| 13:27 | <hallvors> | anything can be misunderstood if you try hard enough |
| 13:30 | Ms2ger | launches an anonymous attack on hallvors |
| 13:31 | hallvors | is a clueless cyber warrior |
| 14:31 | <GPHemsley> | SteveF: I'm kinda bummed you didn't include the alternative suggestions JonathanNeal and I proposed. |
| 14:37 | <zcorpan> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22208 |
| 14:41 | <annevk> | zcorpan: did you clarify that adding them doesn't change the actual namespace map of the style sheet or did you define something else? |
| 14:42 | <annevk> | zcorpan: I don't think there's a namespace map currently and you need to be clear on what happens there |
| 14:42 | <annevk> | zcorpan: e.g. can you change an existing test|test in meaning or not, can you invalidate it, etc. |
| 14:42 | <zcorpan> | annevk: my thinking was that it would change the namespace map, but i haven't really specified how the namespace map works |
| 14:43 | <annevk> | zcorpan: changing the namespace map would potentially require re-parsing selectors, which seems terrible |
| 14:43 | <zcorpan> | annevk: it throws if you try to change @namespace if there are any other rules |
| 14:43 | <zcorpan> | so nothing needs to be reparsed |
| 14:43 | <annevk> | zcorpan: but you can override a previous @namespace |
| 14:43 | <annevk> | zcorpan: ooh sorry |
| 14:43 | <zcorpan> | look at the diff :-) |
| 14:43 | <annevk> | zcorpan: meh |
| 14:44 | <annevk> | :) |
| 14:44 | <GPHemsley> | Hixie: I was kinda hoping you hear your opinion on the whole <hgroup>/<subline> discussion yesterday :) |
| 14:44 | <GPHemsley> | *to |
| 14:51 | <GPHemsley> | We never put together a style guide, did we? |
| 14:51 | <GPHemsley> | I ask because I wonder what our preferred term for dictionary/map/associative array is |
| 14:52 | <GPHemsley> | /object |
| 16:36 | <dglazkov> | good morning, Whatwg! |
| 16:54 | <JonathanNeal> | hello |
| 17:07 | <Ms2ger> | tobie, so why hide the documentation away into another repo? |
| 17:26 | <JonathanNeal> | Do spans or divs imply anything other than logical grouping? |
| 17:33 | <Ms2ger> | No |
| 17:35 | <JonathanNeal> | Are there any best practices for divs and spans that I should know about? |
| 17:36 | <TabAtkins> | Don't overuse them, but don't contort yourself trying to underuse them either? |
| 17:36 | <JonathanNeal> | Like, how liberally can they be used? Is it appropriate to use divs for text-only content, or is it appropriate to put block level elements inside a span? |
| 17:37 | <TabAtkins> | Putting blocks in a <span> will likely have bad layout effects, due to the inline-breaking behavior. Using a <div> for text content is fine if the text is naturally block-like. |
| 17:37 | <TabAtkins> | The default presentation implies a modicum of semantics, but that's it. |
| 17:38 | <JonathanNeal> | I was making a devil's argument in another channel that one could do away with divs. |
| 17:38 | <TabAtkins> | You really can't. And you shouldn't try to. |
| 17:39 | <TabAtkins> | HTML does not and will not try to express all possible semantics. |
| 17:39 | <JonathanNeal> | I'm not sure one "can't". |
| 17:39 | <TabAtkins> | For arbitrary web content, you can't. |
| 17:40 | <JonathanNeal> | I haven't found any situations where a span can't be there, unlike a div, which has restrictions. |
| 17:40 | <TabAtkins> | If you're willing to tweak 'display', a <span> and a <div> are identical, yes. |
| 17:41 | <JonathanNeal> | Except that a <div> will be forced out of certain block level elements, like <p>. |
| 18:25 | <TabAtkins> | JonathanNeal: That's a benefit for those of us who like to utilize end-tag omission. ^_^ |
| 18:38 | <JonathanNeal> | end-tag omission works great until you're next element isn't regularly recognized by IE8. <p>lorem<section>ahhh i didn't break in IE, oh the humanity</section> |
| 18:43 | <TabAtkins> | Don't have to care, wheeee! |
| 18:46 | <JonathanNeal> | :) |
| 19:44 | <tobie> | Ms2ger: re docs: good question. Short answer: it didn't cross my mind (and I guess that's because I don't like having completely different content in branches of the same repository). |
| 19:45 | <jgraham> | branches? |
| 19:46 | <tobie> | branches! |
| 19:51 | <Hixie> | zcorpan: yt? |
| 19:51 | <zcorpan> | Hixie: yes |
| 19:51 | <Hixie> | zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15588 |
| 19:52 | <Hixie> | zcorpan: do you want something from me for this? do you want to take it for now? any input? |
| 19:53 | <Hixie> | also https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 |
| 19:54 | <Hixie> | though presumably that one will definitely require something from me |
| 19:54 | <zcorpan> | Hixie: i don't know. if you have anything useful to add, comment in the bug. i'll take a closer look at it tomorrow |
| 19:58 | <Hixie> | zcorpan: nothing that i haven't already added |
| 19:58 | <Hixie> | zcorpan: thanks |
| 19:59 | <tobie> | Ms2ger: that said, I see benefits to both options and I'm absolutely open to changing if there's consensus to doing so and someone's willing to do the work (migrating GH issues, essentially). |
| 20:00 | <Ms2ger> | tobie, don't feel too strongly either |
| 20:08 | <jgraham> | (I don't see why there would be branches with different content) |
| 20:31 | <zcorpan> | Hixie: if you could file bugs for https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703#c6 that'd be splendid (select text in the spec to file a bug) |
| 20:41 | <zcorpan> | Hixie: maybe HTML needs to use something along the lines of http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction for <link>? |
| 20:45 | <zcorpan> | man, the xml-stylesheet spec is horrible to read, being in terms of infoset |
| 20:45 | <zcorpan> | "[Definition: A processing instruction information item is said to be a potential xml-stylesheet processing instruction if it has the [target] property xml-stylesheet and it either is in the [children] property of a document information item and appears before the element information item of the document information item's [children] property, or it appears in the [children] property of a document type declaration informat |
| 20:45 | <zcorpan> | ion item.]" |
| 20:57 | <Hixie> | zcorpan: yeah, i assume so |
| 20:58 | <Hixie> | zcorpan: and yes, will file bugs |
| 20:58 | <zcorpan> | thanks! |
| 21:00 | <Hixie> | am i dumb? why is firefox giving me NS_ERROR_FAILURE on http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2266 ? |
| 21:03 | <Hixie> | seems to work in hixie.ch/www/tests/adhoc/dom/level0/history/pushState/003.html |
| 21:03 | <Hixie> | er, http://www.hixie.ch/tests/adhoc/dom/level0/history/pushState/a/b/c/ |
| 21:03 | <Hixie> | er |
| 21:03 | <Hixie> | er, http://www.hixie.ch/tests/adhoc/dom/level0/history/pushState/003.html |
| 21:03 | <Hixie> | sheesh |
| 21:05 | <Hixie> | well webkit's behaviour is odd |
| 21:16 | GPHemsley | gets "error: NS_ERROR_XPC_NOT_ENOUGH_ARGS: Not enough arguments [nsIDOMHistory.pushState] on line 5" on the first link |
| 21:16 | <GPHemsley> | Hixie: ^ |
| 21:19 | <zcorpan> | how do people pronounce "@charset"? is it "charset" or "at-charset"? |
| 21:20 | <divya> | why dont you ask twitter zcorpan |
| 21:20 | <Hixie> | GPHemsley: sorry, i meant http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2267 |
| 21:21 | <zcorpan> | divya: done |
| 21:21 | <zcorpan> | divya: now you have to answer the question :-P |
| 21:22 | <Hixie> | it's pronounced at-car-set |
| 21:22 | <divya> | who is the inventor of charset |
| 21:22 | <divya> | plz give that person a webby award |
| 21:22 | <divya> | and ask how to pronounce it |
| 21:22 | <zcorpan> | Hixie: even if the next word is "at-rule"? |
| 21:22 | <Hixie> | divya: so you know what the wrong way to pronounce it is? :-P |
| 21:22 | <Hixie> | zcorpan: know, the next word is just "rule" |
| 21:23 | <Hixie> | er |
| 21:23 | <Hixie> | "no" |
| 21:23 | <Hixie> | not "know" |
| 21:23 | <Hixie> | man |
| 21:23 | <divya> | Hixie: i have always said CHHHAR |
| 21:23 | <divya> | not car |
| 21:23 | <Hixie> | k-har? |
| 21:23 | <Hixie> | or tshar? |
| 21:23 | <divya> | TSHARRR |
| 21:23 | <divya> | English sucks |
| 21:23 | <Hixie> | it's not tshar |
| 21:23 | <Hixie> | it's short for "character" |
| 21:23 | <divya> | yes i knooo |
| 21:23 | <divya> | but i cannot get myself to say car |
| 21:24 | <Hixie> | (a lot of people agree with you) |
| 21:24 | <zcorpan> | Hixie: css-syntax uses "at-rule" so i wanted to hook in to that :-| |
| 21:24 | <Hixie> | (you're all wroooong) |
| 21:24 | <divya> | ALL WRONG! |
| 21:24 | <divya> | what did I tell you zcorpan |
| 21:24 | <divya> | like 100 responses |
| 21:24 | <divya> | everyone likes to bikeshed |
| 21:24 | <divya> | its delightful waste of our time |
| 21:24 | <Hixie> | zcorpan: i would say "an at-rule" and "an at-car-set rule" |
| 21:24 | <Hixie> | sometimes maybe "an at-car-set at-rule" |
| 21:25 | <zcorpan> | poor @charset on twitter will wonder what the buzz is about |
| 21:25 | <divya> | hahah |
| 21:27 | <GPHemsley> | Shouldn't annevk have that account? |
| 21:27 | <GPHemsley> | @charizard |
| 21:27 | <GPHemsley> | better watch out for that rule |
| 21:28 | <Hixie> | -_- |
| 21:29 | <GPHemsley> | ^_^ |
| 21:32 | <zcorpan> | Hixie: something being an abbreviation of something else doesn't imply that it's pronounced as part of the original word |
| 21:34 | <Hixie> | counter example? |
| 21:35 | <zcorpan> | Hixie: do you say "car" with the "a" as in "park" or with the "a" as in "character"? |
| 21:36 | <zcorpan> | (i guess the latter would be more like "care") |
| 21:37 | <Hixie> | i pronounce the a in car the same as in cart, park, lark, farm |
| 21:37 | <Hixie> | so i guess, fair enough |
| 21:38 | <zcorpan> | :-) |
| 21:39 | <Hixie> | in other news, i can never figure out insertBefore()'s arguments |
| 21:39 | <zcorpan> | yeah same here. i always get them wrong on the first try |
| 21:43 | <Hixie> | anyone disagree with my logic for base URLs in the source of http://www.hixie.ch/tests/adhoc/dom/level0/history/pushState/003.html ? |
| 21:44 | <Hixie> | (note that WebKit doesn't do it that way) |
| 21:44 | <Hixie> | (but Gecko seems to) |
| 21:45 | gavinc | has oddly been staring at baseuri and pushstate all week |
| 21:45 | gavinc | goes to read |
| 21:47 | <gavinc> | Restating base doesn't change anything in HTML? |
| 21:47 | <Hixie> | only the first <base href> matters |
| 21:48 | <gavinc> | the comment on 24 is wrong |
| 21:48 | <gavinc> | but the result is correct |
| 21:48 | <gavinc> | At least my reading ;) |
| 21:48 | <gavinc> | It's 'cause the base url before d is now set from back at line 16 |
| 21:48 | <gavinc> | right? |
| 21:49 | <gavinc> | Nothing magic about "remembering" the base from the old <base> |
| 21:49 | <Hixie> | how is it wrong? |
| 21:49 | <Hixie> | i don't follow |
| 21:50 | <Hixie> | (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=18459#c11 for context btw) |
| 21:50 | <gavinc> | Right! |
| 21:51 | <gavinc> | and when it gets resolved, it's resolved realitive to the current document URI which is now the base since the old <base> went away |
| 21:51 | <gavinc> | the "remembered" bit is confusing to me |
| 21:51 | <gavinc> | there just isn't a <base> anymore, so it's the document URI again |
| 21:52 | <gavinc> | and then there is a base again so add d/ |
| 21:52 | <Hixie> | by "remembered" i mean "stored for future use" |
| 21:52 | <gavinc> | ... I don't think it is however... |
| 21:52 | <gavinc> | is it? |
| 21:52 | <Hixie> | if it wasn't, the base URL would have to be recomputed each time it was needed |
| 21:52 | <gavinc> | Isn't it just dropping back to the Document URI |
| 21:52 | <Hixie> | so the pushState() calls would matter |
| 21:52 | <Hixie> | s/matter/immediately change the base URL/ |
| 21:53 | <Hixie> | reload to see new phrasing of comments |
| 21:54 | <gavinc> | Okay, now I agree, yes :D |
| 21:54 | <Hixie> | excellent |
| 21:55 | <gavinc> | ... base uri is hard to explain... |
| 21:55 | <Hixie> | little bit |
| 22:50 | <TabAtkins> | zcorpan: I usually pronounce it "at-charset", but use a/an as if it started with "c". |
| 22:51 | <zcorpan> | TabAtkins: that doesn't make sense |
| 22:51 | <TabAtkins> | zcorpan: I'm not super-consistent with this, but I decided on this pattern a while ago in my specs and try to stick to it. |
| 22:51 | <TabAtkins> | zcorpan: When writing, that is. |
| 22:51 | <TabAtkins> | When speaking, since I'm pronouncing the "at", I use "an". |
| 22:52 | <zcorpan> | ok. i use an in cssom now. |
| 22:54 | <TabAtkins> | It's not really important, so whatever. English's a/an thing is dumb. |
