| 02:19 | <boblet> | In links.html#other-link-types the spec mentions extensions to rel values can be added to the microformats.org wiki, inc. synonyms and status. Linked microformats.org table lacks synonyms and status columns in tables, although status is inferable |
| 02:27 | <boblet> | how does http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html affect links.html#link-types and links.html#other-link-types ? |
| 02:28 | <boblet> | aah, “Check-in comment: Drop support for rel=up, rel=last, rel=index, rel=first, and |
| 02:28 | <boblet> | any related synonyms.” somewhat less extensive than issue 118’s text |
| 02:49 | <boblet> | hsivonen: are you planning to add support for the rel values mentioned on microformats.org wiki to validator.nu? e.g. edituri, canonical (POSH table), and index, start (other specs table) |
| 02:50 | <boblet> | hsivonen: alternatively would it be possible for validator-unknown rel values to be flagged as warnings rather than errors, since they may be valid? |
| 06:34 | <hsivonen> | http://www.jenitennison.com/blog/node/157 |
| 07:25 | <boblet> | hsivonen: yt? |
| 08:43 | <hsivonen> | boblet: here now |
| 08:49 | <boblet> | hsivonen: I left some questions in chat about rel values and validator.nu about 6 hours ago, finding link now… |
| 08:49 | <boblet> | http://krijnhoetmer.nl/irc-logs/whatwg/20110613 |
| 08:51 | <hsivonen> | boblet: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032014.html |
| 08:52 | <hsivonen> | boblet: validator.nu considers the keywords that meet the registration requirements but aren't dropped HTML 4 link types as valid |
| 08:53 | <hsivonen> | boblet: that is, stuff from the HTML5 link type extensions table and non-HTML 4 stuff from the Formats table |
| 08:53 | <hsivonen> | boblet: still trying to work out what the right thing to do is for the HTML 4 keywords that got dropped |
| 08:54 | <hsivonen> | boblet: I suppose the keywords dropped by http://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html should be considered unregistrable |
| 09:04 | <hsivonen> | oh the WG Decision explicitly allows registration of the dropped types |
| 09:04 | <hsivonen> | how is that useful? |
| 09:17 | <hsivonen> | Hixie: I'm not a big fan of "If a keyword is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry." |
| 09:18 | <hsivonen> | I think it makes more sense to take specless proposals out immediately |
| 09:18 | <hsivonen> | (and allow the to be put back when someone bothers to come up with a spec liink) |
| 09:18 | <hsivonen> | Hixie: how would one discover that a keyword is not being used? |
| 09:32 | <hsivonen> | looks like the geographic location meta keywords are a standardization failure |
| 09:33 | <hsivonen> | at least 3 different ways to say the same thing |
| 09:54 | <boblet> | hsivonen: sorry for being afk and thanks for your feedback |
| 10:07 | <hsivonen> | boblet: would you like to register a keyword that was in HTML 4 but isn't in HTML5? |
| 10:50 | <boblet> | hsivonen: it’s more there are a bunch in WordPress or that we’ve accumulated in HTML5Doctor, and in investigating the situation it seems strange that there’s a process for adding these, but even if added they can be flagged as errors (vs warnings) by a validator |
| 10:51 | <boblet> | hsivonen: aware that validation is just a tool, most of them aren’t required etc. I’ll think over what you’ve written/linked to and give some feedback in a bit |
| 12:55 | <smaug____> | the HTMLElement attribute <-> content attribute mapping is just strange |
| 12:55 | <jgraham> | hsivonen: I think the interesting thing from http://www.w3.org/2010/02/rdfa/meetings/2011-06-09 is that all their discussion starts "lets assume a person that wants to use RDFa…" |
| 12:55 | <smaug____> | but nothing new in HTML spec |
| 12:56 | <jgraham> | That suggests they won't be very successful in reexamining earlier ideas about simplification because their mental model is "lets assume that most users are just like me" |
| 12:57 | <Dashiva> | Anything in particular, smaug____, or just in general? |
| 12:59 | <smaug____> | in general. |
| 13:00 | <smaug____> | Setting element.contextMenu may magically set element's content attribute |
| 13:00 | <matjas> | What does “ISO 10646 characters U+00A0 and higher” mean exactly? Characters in the range \u000 – \uFFFF, or is that too limited? |
| 13:01 | <smaug____> | yet if the menu element is removed from DOM, the content attribute still has its ID as value |
| 13:01 | <matjas> | (Read that in the CSS spec — just asking here first.) |
| 13:02 | <matjas> | \u0000* |
| 13:02 | <Dashiva> | \u00A0 surely |
| 13:03 | <smaug____> | The spec really needs more reviewing |
| 13:03 | <matjas> | Dashiva: yeah, sorry :) |
| 13:04 | <matjas> | but what would you guys consider the upper limit if that’s all the spec says? |
| 13:05 | <Dashiva> | I can't say for sure without reading it, but I would parse "ISO 10646 characters" to include code points above \uFFFF too |
| 13:10 | <matjas> | Dashiva: so up to \u10FFFF? |
| 13:11 | <matjas> | Dashiva: If you feel like reading: http://www.w3.org/TR/CSS2/syndata.html#value-def-identifier |
| 13:15 | <Dashiva> | Yeah, I would say this confirms it: "the backslash is followed by at most six hexadecimal digits (0..9A..F), which stand for the ISO 10646 ([ISO10646]) character with that number" |
| 13:15 | <Dashiva> | "If the number is outside the range allowed by Unicode (e.g., "\110000" is above the maximum 10FFFF allowed in current Unicode)" |
| 13:16 | <matjas> | Dashiva: Thanks! I should’ve kept reading, I guess. |
| 13:37 | <hsivonen> | jgraham: yeah. assuming that Web authors want to use RDFa (or Microdata for that matter) is FAIL |
| 13:37 | <hsivonen> | Web authors don't care about your metadata framework |
| 13:38 | <hsivonen> | they care about their client's marketing dept requiring Facebook Like buttons |
| 13:38 | <hsivonen> | or doing SEO |
| 13:42 | hsivonen | finds out about w3schools Online Certification Program |
| 13:42 | <hsivonen> | $95 per certificate |
| 13:42 | <hsivonen> | that's so sad |
| 13:59 | <boblet> | hsivonen: what’s sad is w3schools showing in the top of results when their info is often so crap (ref http://w3fools.com/ ), and the perception that they’re good or even _official_ among new coders b/c of the w3 |
| 14:00 | <hsivonen> | boblet: yeah. I wonder how many bug reporting systems could use a "Please read http://w3fools.com/ before filing bugs." message |
| 14:02 | <boblet> | har! to be fair, they’ve fixed some of those, but still it’s pretty atrocious. The guy is def. in it solely for the ad revenue |
| 14:02 | <hsivonen> | I wonder when we are going to see the first meta or rel keyword registration that puts a w3schools URL in the spec column |
| 14:02 | <hsivonen> | boblet: "the guy"? I thought it was a whole family |
| 14:02 | <boblet> | sad when things like MDC are better and lower in the result list |
| 14:02 | <Dashiva> | So I'm thinking... |
| 14:03 | <boblet> | ohrly? heh, family enterprise eh |
| 14:03 | <Dashiva> | Since everyone in linked data hates DE lately, could we just get rid of DE in microdata and go back to centralized vocabularies only? |
| 14:03 | <boblet> | yay capitalism |
| 14:04 | <boblet> | Dashiva: kinda defeats the purpose of adding something to HTML5 to keep pro-extensible ppl happy |
| 14:04 | <boblet> | (not that it did, of course) |
| 14:05 | <Dashiva> | But they've made it clear they don't want it |
| 14:05 | <hsivonen> | Dashiva: what about DE in RDF? |
| 14:06 | <boblet> | for ppl without a religion microdata is pretty sweet tho |
| 14:07 | <cvn> | so it's official, i left the w3c html wg, not that i think i will be missed much as i hardly ever contributed anything anyway :) |
| 14:07 | <cvn> | but i'm not going to lie, i got rather pissed off after the thread re w3c/whatwg politics |
| 14:08 | <Dashiva> | hsivonen: Not like anyone ever uses it in the real world, they all use the same handful of vocabularies |
| 14:08 | <cvn> | i mean what is this crap re not being able to disguss this nonsense publicly, what is so "sensitive" about it |
| 14:10 | <hsivonen> | cvn: pissed off at whom? |
| 14:11 | <cvn> | hsivonen: nobody in particular, just this action of "oh there's politics, let's keep this off-list" |
| 14:11 | <cvn> | s/action/concept/ |
| 14:11 | <cvn> | if anything, people should discussing this nonsense out in the open |
| 14:12 | <cvn> | atm from my perspective html is getting "forked" |
| 14:12 | <Dashiva> | Oddly enough, the people talking nonsense don't like doing it in public |
| 14:12 | <cvn> | s/forked/borked/ - either would work |
| 14:12 | <smaug____> | Ms2ger: volkmar: does something in the spec specify what "first img element descendant of the element" mean? |
| 14:12 | <cvn> | Dashiva: yeah i guess... figures :) |
| 14:13 | <hsivonen> | cvn: who do you see as doing the forking? |
| 14:13 | <smaug____> | Ms2ger: volkmar: I assume document order, but can't be sure... |
| 14:13 | <cvn> | hsivonen: that's a very good question, i actually don't know |
| 14:13 | <cvn> | who has "claim" to html - whatwg or w3c? |
| 14:14 | <cvn> | imho it's an internet standard and belongs to the global general public, not to anyone |
| 14:14 | <hsivonen> | cvn: I think the power game is detrimental |
| 14:15 | <cvn> | exactly |
| 14:15 | <cvn> | i mean c'mon, can't we just kiss and make up, seriously |
| 14:15 | <Dashiva> | HTML5 happened because reality didn't listen to the claims of ownership |
| 14:15 | <hsivonen> | cvn: as I see it, part of the revert requests and issues are attempts to demonstrate some kind of W3C process power |
| 14:15 | <hsivonen> | (how dare anyone write anything about accessibility without consulting the WAI?) |
| 14:15 | <cvn> | this is where company / individual agenda starts to negatively affect the state of human being :) |
| 14:16 | <cvn> | the w3c is still the same as always - it's a bureaucracy |
| 14:16 | <hsivonen> | cvn: and then Hixie refuses to apply even trivial changes to the WHATWG copy--presumably in order to avoid giving in to the power demonstration of steve et al. and to avoid going on a slippery slope to more and more compromise |
| 14:16 | <Dashiva> | hsivonen: wwic? :) |
| 14:17 | <volkmar> | smaug____: i don't know of any definition of this on top of my head but i would assume tree order |
| 14:17 | <cvn> | cvn: yeah this is where all logic has left the building :) |
| 14:17 | <Dashiva> | TabAtkins_, re: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12849 someone was asking about that same thing because webkit was displaying thousands separators with type=number |
| 14:18 | <cvn> | aargh mant to type hsivonen, not talk to myself lol |
| 14:18 | <cvn> | freudian slip |
| 14:18 | <hsivonen> | Dashiva: I think there might be a certain amount of WWIC going on in the WAI relationship, yeah |
| 14:19 | <smaug____> | volkmar: just assuming something when reading a spec feels wrong :) |
| 14:19 | <smaug____> | but ok, I'll file a bug |
| 14:19 | <volkmar> | smaug____: plz, CC me :) |
| 14:19 | <cvn> | ok i'm off, just came in here to gripe apparently :) |
| 14:25 | <Dashiva> | cvn: I imagine your stress levels will be going down after leaving the group |
| 14:28 | <zcorpan> | hsivonen: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12935 - "If we only did what Hixie said, we'd lose implicit closing of rb and rp in the |
| 14:28 | <zcorpan> | simple Ruby case." - not AFAICT, since "generate implied end tags" closes rb and rp |
| 14:29 | <zcorpan> | hsivonen: i'm not convinced there's a need to aggressively pop stuff inside <ruby> |
| 14:30 | Dashiva | laughs at w3c being compared to the UN as if it's a good thing |
| 14:30 | <hsivonen> | zcorpan: oh. that's worth saying on the bug |
| 14:32 | <zcorpan> | done |
| 14:46 | <hsivonen> | zcorpan: thanks |
| 14:48 | <zcorpan> | hsivonen: iirc old ie didn't do aggressive popping |
| 14:48 | <hsivonen> | zcorpan: ok |
| 15:19 | <zcorpan> | jgraham: it was a design mistake to put the description last in test(func, desc) |
| 15:20 | <zcorpan> | jgraham: since i want to read the description before reading the test block |
| 15:25 | <Philip`> | Change it to accept both argument orders, by checking the types |
| 15:38 | <jgraham> | zcorpan: The idea is sort of that desc is optional. That might itself be a mistake ofc |
| 15:39 | <jgraham> | Philip`: That way lies badness I think. AT least where I already did things like that I later wished I hadn't |
| 15:40 | <zcorpan> | jgraham: being optional makes sense if there's only one test |
| 15:41 | <zcorpan> | it's not a biggie, it's just that i need to jump back and forth when reviewing a testsuite |
| 16:32 | <smaug____> | Hixie: ping |
| 16:39 | <smaug____> | or anyone. how does one trigger an Action (other than using an access key)? |
| 16:51 | <Dashiva> | smaug____: Depends on the command it's tied to. Click a link, select a menu item, etc. |
| 16:51 | <smaug____> | Dashiva: and where is that defined? |
| 16:52 | <smaug____> | there is also non-normative text that calling element.click() triggers the action, but I couldn't find any normative text |
| 16:55 | <Dashiva> | 3.2.5.1.7 Interactive content covers click activation |
| 16:56 | <Dashiva> | 4.11.5 Commands is also relevant |
| 16:57 | <smaug____> | I couldn't find the definition for triggering a command |
| 16:57 | <smaug____> | 3.2.5.1.7 is clear |
| 16:58 | <smaug____> | but it isn't about commands |
| 17:00 | <Dashiva> | Oh, I see what you mean |
| 17:02 | <Dashiva> | Apart from click() I think it's up to the UA to expose commands |
| 17:04 | <smaug____> | if that is the case, it sure should be said somewhere |
| 17:05 | <Dashiva> | Yeah, a come-from table would be useful instead of just having gotos elsewhere |
| 17:07 | <smaug____> | especially because the gotos end up to /dev/null |
| 17:08 | <Dashiva> | Hm? |
| 17:08 | <smaug____> | I mean, things aren't specified properly |
| 17:08 | <smaug____> | I assume commands part of the spec hasn't been reviewed yet |
| 17:09 | <Dashiva> | The commands part defines commands. Other parts of the spec use commands, those define how they invoke commands. |
| 17:09 | <smaug____> | (I'm just reviewing a patch implementing it and I need to understand what the commands is about) |
| 17:09 | <Dashiva> | E.g. the accesskey section defines and invokes a command |
| 17:09 | <smaug____> | (so far few bugs found in the spec) |
| 17:16 | <jgraham> | smaug____: The reality is that the spec gets well reviewed when people first implement it |
| 17:17 | <smaug____> | jgraham: indeed |
| 17:17 | <jgraham> | It seems that you just won (lost) on this occasion |
| 17:17 | <smaug____> | and in some cases not even when implementing :p |
| 17:17 | <jgraham> | Yeah :( |
| 17:19 | <smaug____> | I haven't actually implemented too much of HTML, but I've reviewed quite a bit code implementing it. And reviewing that code tend to be quite slow since one needs to first review the relevant parts of the spec, file spec bugs, get them fixed and then also review the actual code |
| 17:21 | <jgraham> | I am currently sitting in the same room as people doing that for a different part of the spec, so I sympathise with the situation :) |
| 17:21 | <smaug____> | But I'm a bit worried that only implementors review the spec |
| 17:21 | <smaug____> | we should get web devs to look at it too |
| 17:21 | <jgraham> | Well authors only care about things that are implemented |
| 17:21 | <jgraham> | So there is a problem there |
| 17:22 | <smaug____> | but we might get some silly feature implemented which no one will use |
| 17:22 | <jgraham> | And authors who care about things that aren't yet implemented tend to become implementors rather quickly |
| 17:22 | <smaug____> | :) |
| 17:23 | <jgraham> | smaug____: Yeah, there is some responsibility for implementors to push back on features they think won't be used |
| 17:23 | <jgraham> | Which means that you have to listen to your users and the wider community and so on |
| 17:29 | <TabAtkins_> | Ideally, the "formulate use-cases that actually exist" step of proposing new features involves talking to web authors. |
| 17:29 | <TabAtkins_> | Or being one. |
| 17:34 | <Dashiva> | Well, it's not like we're inventing features out of whole cloth |
| 17:37 | <Ms2ger> | Oh? |
| 17:37 | <TabAtkins> | I don't use half-cloth in my designs, that's for sure. |
| 17:44 | jgraham | only invents features out of whole goth |
| 17:44 | <TabAtkins> | Too bad gsnedders isn't in the office anymore, then. |
| 17:45 | <jgraham> | We sent him away to replenish his gothness |
| 17:54 | <TabAtkins> | This is great: http://whereswalden.com/2011/02/03/working-on-the-js-engine-episode-iv/ |
| 17:55 | <Ms2ger> | Yeah, Mozilla people usually are :) |
| 18:14 | <oal> | In html5, am I allowed to invent my own html attributes? like <div help="This is..."></div>? |
| 18:14 | <oal> | And use that data from javscript? |
| 18:14 | <TabAtkins> | oal: Yes, but you have to prefix them with "data-". So <div data-help="This is..."></div> |
| 18:15 | <oal> | TabAtkins: aha, clever! Thank you very much :) |
| 18:15 | <oal> | Makes it easier to see what's my attributes vs traditional attributes |
| 18:16 | <TabAtkins> | Exactly. Any data-* attribute is just private script data you're attaching to DOM nodes for convenience, rather than holding in pure javascript. |
| 18:17 | <oal> | :) |
| 18:20 | <AryehGregor> | Also, in newer browsers you have a convenient way to access the data, like div.dataset.help = 'foo' instead of div.setAttribute("data-help", "foo"). |
| 18:22 | <oal> | The future of the web looks bright with all the new html5, css3 and js apis :) |
| 18:45 | <scor> | mpilgrim: http://schema.org/person and http://schema.org/address should be upper case in http://diveintohtml5.org/extensibility.html |
| 19:06 | <oal> | Is it ok to wrap a label around an input like <label><input /></label> or should you use <label for="idOfInput">...</label>? |
| 19:06 | <TabAtkins> | The former is perfectly fine, and is way easier when your markup structure allows it. |
| 19:08 | <oal> | Yup, agreed :) |
| 19:15 | AryehGregor | likes how this credit card application form doesn't use autocomplete=false on the SSN field |
| 19:15 | <Ms2ger> | Add it with your devtools? :) |
| 19:15 | <TabAtkins> | I've never used autocomplete=false. :/ |
| 19:20 | <AryehGregor> | TabAtkins, you don't write bank websites, I hope. |
| 19:20 | <TabAtkins> | No, but I have written sites that ask for CC info. |
| 19:20 | <AryehGregor> | And you didn't use autocomplete=false? Isn't that kind of thing required for whatever certification you need to accept credit cards online? |
| 19:20 | <TabAtkins> | Presumably not? |
| 19:21 | <AryehGregor> | Or do they just require HTTPS so that you get the little lock icon and your users feel secure and don't blame the site when their credit card info is stolen? |
| 19:21 | <TabAtkins> | Likely that. |
| 19:21 | <Ms2ger> | W3Schools certification, you mean? :) |
| 19:21 | <TabAtkins> | I dunno, I never read any certification requirements. |
| 19:21 | <TabAtkins> | The site as a whole was pretty shitty code in retrospect, but it was very good for me at the time. |
| 19:22 | <AryehGregor> | https://www.pcisecuritystandards.org/ |
| 19:22 | <AryehGregor> | Nice, the official PCI site includes mixed content and gets the little red cross-out thing in Chrome. |
| 19:22 | <TabAtkins> | Interestingly, that site has mixed content warnings. |
| 19:23 | <zewt> | firefox "helpfully" remembers my credit card number all the time, i'm always deleting it. heh |
| 19:24 | <AryehGregor> | https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf |
| 19:24 | <AryehGregor> | It looks like nothing says you should prevent client-side caching of sensitive data. |
| 19:24 | <AryehGregor> | At least glancing at the ToC. |
| 19:25 | <zewt> | there's also the regional ... either gas or electric company's website, which uses some hidden Flash thing to log in "securely", and the actual login page shows up as HTTP |
| 19:25 | <AryehGregor> | It does require encryption. |
| 19:25 | <zewt> | always nice to batch-train people to ignore HTTPS ... |
| 19:25 | <hsivonen> | AryehGregor: my browser already remembers my paypal password. surely it would be nice for it to remember my credit card number, too |
| 19:26 | <AryehGregor> | My browser doesn't remember my bank password or Google password. |
| 19:26 | <AryehGregor> | At least with passwords, it asks you before remembering them. |
| 19:26 | <zewt> | firefox always remembers the wrong Google password for me; no matter how many times I reenter it, it never offers to update it. heh |
| 19:26 | <hsivonen> | my browser doesn't remember my bank passcodes, because they are different on each login |
| 19:26 | <zewt> | i should just edit the database directly or whatever to convince it to update |
| 19:28 | hsivonen | could use a way to edit the remembered form data in Firefox |
| 19:28 | <AryehGregor> | This standard actually seems pretty reasonable. |
| 19:28 | <AryehGregor> | hsivonen, sqlite on command line? |
| 19:28 | AryehGregor | has used that sometimes |
| 19:29 | <hsivonen> | AryehGregor: not really the ideal UI |
| 19:29 | <TabAtkins> | Is it defined somewhere in the spec that DOM trees are by default sorted in document order, so that statements about "select the first X" are unambiguous? |
| 19:29 | <AryehGregor> | Well, not for changing individual rows, no. |
| 19:29 | <AryehGregor> | TabAtkins, I make that explicit in the edit commands spec, but I dunno if it's clear elsewhere. |
| 19:30 | <AryehGregor> | "When a list or set of nodes is assigned to a variable without specifying the order, they must be initially in tree order, if they share a root. (If they don't share a root, the order will be specified.) When the user agent is instructed to run particular steps for each member of a list, it must do so sequentially in the list's order." |
| 19:30 | <AryehGregor> | That more or less covers it, I think. |
| 19:30 | <AryehGregor> | Although really, I don't think any implementers are going to be confused here. |
| 19:30 | <TabAtkins> | Right, but still, best not to leave things undefined when we can define them. |
| 19:31 | <AryehGregor> | Clearly I agree, which is why I defined it. :) |
| 19:33 | <AryehGregor> | Capital One's website also doesn't allow "special characters" in the street address, which includes periods. |
| 19:33 | <AryehGregor> | No "Ave." for me. |
| 19:33 | <TabAtkins> | I usually write it as "Ave" anyway. |
| 19:33 | <TabAtkins> | Unrelated: WUT 11:26 < AryehGregor> https://www.pcisecuritystandards.org/ |
| 19:33 | <TabAtkins> | Shit, wrong one. |
| 19:33 | <TabAtkins> | Unrelated: WUT http://i.imgur.com/lxlJf.gif |
| 19:33 | <TabAtkins> | There we go. |
| 19:34 | <AryehGregor> | Looks totally Photoshopped. |
| 19:35 | <TabAtkins> | I can see the pixels. |
| 19:36 | <zewt> | among my favorites was a site with a phone number entry that I pasted into, which proceeded to paste "(123) 456-" into their "1234567890" field skipping their broken validation, and then it wouldn't let me backspace over the entry (because the intermediate backspaced data failed the validation and cancelled the input) |
| 19:41 | <AryehGregor> | That kind of validation is great. |
| 19:41 | <AryehGregor> | I'm waiting for HTML5 form inputs to catch on. |
| 19:43 | <zewt> | not much hope for that ... "tier" of developers ever using something sane, though |
| 19:44 | <Ms2ger> | OTOH, lazyness might make them use WF2 |
| 19:44 | <AryehGregor> | zewt, they will if it's easier. |
| 19:45 | <AryehGregor> | Ooh, the site also has required security questions. |
| 19:46 | <AryehGregor> | I have to pick three questions to give the answers to, out of five choices. |
| 19:46 | <AryehGregor> | Of the five choices they offer, one makes no sense, I have no idea what the answer is to another, and the other three would be really easy for anyone to find out (or in some cases guess). |
| 19:47 | <zewt> | because security is about having lots of powerpoint slides to show the CEO, even if it's worse than nothing and cripplingly inconvenient for users |
| 19:47 | <AryehGregor> | Yep. |
| 19:47 | <AryehGregor> | Which is why mandatory security standards are often good, because you have some slight hope that the people who write them aren't complete idiots. |
| 19:47 | <AryehGregor> | (I mean, mandatory for things like bank sites) |
| 19:49 | <AryehGregor> | My approach is to fill in the answers with "cat /dev/urandom | tr -cd ' -~' | head -c 20; echo" and record the answers in a file on my home directory. |
| 19:51 | <AryehGregor> | Please enter a valid answer using only letters, numbers spaces & special characters -'.,&@:?!()$#/\ . |
| 19:51 | <AryehGregor> | Because that makes it much more secure. Sigh. |
| 19:54 | Hixie | peeks in |
| 19:55 | <Ms2ger> | Evening |
| 20:01 | <scor> | Hixie: I summarized the microdata multitype conversation we had last week, maybe the examples I use there will make more sense? http://openspring.net/blog/2011/06/10/microdata-multiple-vocabularies |
| 20:03 | <scor> | of course any feedback or correction on what I said in this post are more than welcome! |
| 20:09 | <jgraham> | Someone should fix the planet.mozilla.org software to close out all the elements from each blog post before starting the next one |
| 20:09 | <Ms2ger> | That's to annoy people who use Opera |
| 20:10 | <AryehGregor> | What's the issue, a parser difference? |
| 20:11 | jgraham | was reding it in Firefox s it happens :) |
| 20:11 | <jgraham> | add "a" liberally |
| 20:12 | <jgraham> | In Opera it works fine... |
| 20:14 | <jgraham> | Hmm, it also work in Chrome |
| 20:14 | <jgraham> | That is quite strange |
| 20:23 | <TabAtkins> | AryehGregor: The correct answer to security questions is always another password. |
| 20:23 | <AryehGregor> | TabAtkins, yes. |
| 20:24 | <jgraham> | Oh. It is being parsed as text/html in Gecko and application/xhtml+xml elsewhere |
| 20:26 | <AryehGregor> | Weird, why? |
| 20:27 | <Hixie> | scor: i don't really understand what problem any of the annotations are solving for you, so it's hard for me to make a recommendation |
| 20:27 | <Hixie> | scor: i mean, why doesn't omitting all microdata work equally well? |
| 20:28 | <Hixie> | oops, got the wrong annotation on the last checkin |
| 20:28 | <Hixie> | crap |
| 20:28 | <scor> | Hixie: omitting all md means no structured data |
| 20:28 | <Hixie> | scor: right |
| 20:28 | <Hixie> | scor: why isn't that good enough for you? |
| 20:28 | <Hixie> | scor: what are you using this data for? |
| 20:29 | <scor> | Hixie: I'm not using this data, I'm only publishing it, hoping others will use it |
| 20:29 | <scor> | Hixie: I'm only a publisher, not a consumer |
| 20:30 | <scor> | but there can be many different consumers which might not agree on a given schema/vocab (e.g. currently google and facebook) |
| 20:30 | <Hixie> | ok well if you're just hoping someone will use it, odds are very good that nobody is using it |
| 20:30 | <scor> | publishers should have the right to use different vocab |
| 20:30 | <Hixie> | so i would save yourself a lot of time and not bother |
| 20:30 | <scor> | Hixie: well, that's just because you don't believe in structured data :) |
| 20:31 | <Hixie> | i don't _believe_ in anything |
| 20:31 | <Hixie> | structured data is not special in this :-) |
| 20:31 | <scor> | Hixie: but I think I understand where your confusion was coming from, you assumed I was buliding some app on top of that data |
| 20:31 | <scor> | I see |
| 20:31 | <scor> | but the publisher and the consumers are decoupled |
| 20:31 | <Hixie> | microdata is intended for concrete uses, yes, not hypothetical hopeful uses :-) |
| 20:33 | <AryehGregor> | scor, generally HTML5 and related things are developed on the basis of concrete use-cases. That means things that people directly and tangibly benefit from. Without use-cases, we can't evaluate whether a proposed feature or change is worth the effort to implement it. |
| 20:34 | <AryehGregor> | If you're just putting up the data and don't have reason to believe anyone will use it, then there are no grounds for us to judge the usefulness of your proposed changes relative to other changes we could make for the same effort. |
| 20:34 | <scor> | AryehGregor, Hixie I see your points re concrete use cases |
| 20:34 | <AryehGregor> | Or really, there's no grounds for us to believe that your proposed changes are useful at all. |
| 20:36 | <scor> | zcorpan: seen this? summarizes the situation re the snippet you gave me the other day: http://openspring.net/blog/2011/06/10/microdata-multiple-vocabularies |
| 20:52 | <zcorpan> | scor: hadn't seen it |
| 21:59 | jgraham | hadn't seen http://www.w3.org/2010/12/community/summary before |
| 22:01 | <karlcow> | jgraham: seeAlso http://www.w3.org/QA/2011/04/coming_soon_w3c_community_grou.html |
| 22:01 | jgraham | wonders what would have happened if in 2004 someone had proposed a community group to work on HTML... |
| 22:02 | <zcorpan> | what happens if we propose a community group to work on HTML today? |
| 22:02 | <jgraham> | Because WHATWG sounds an awful lot like a "community group" |
| 22:02 | <karlcow> | it's an evolution. |
| 22:03 | <karlcow> | it helps answer a need that w3c was not able to answer in 2004. |
| 22:07 | <jgraham> | karlcow: I expect the W3C would not want a community group competing with a ordinary WG |
| 22:08 | <jgraham> | It doesn't say anywhere that they will accept all submissions |
| 22:09 | <karlcow> | jgraham: I believe in quite the opposite. The community group, for me, is here to leave a possibility of exploring a topic. |
| 22:09 | <karlcow> | Member submissions have been traditionally been very open, but reserved to members. |
| 22:10 | <karlcow> | Community group is more open, so it is quite cool to see that development. |
| 22:10 | <karlcow> | It gives an interesting avenue for discussing things, hacking, etc. It's quite cool. |
| 22:10 | <jgraham> | Oh, I'm not saying it is bad |
| 22:11 | <zcorpan> | i wonder if the Business Group thing is going to be used |
| 22:11 | <karlcow> | I prefer to look at it as a tool and trying it and we will see how far the rest of W3C communities react to it. |
| 22:11 | <karlcow> | learning from each other |
| 22:12 | <jgraham> | But until it happens, I will remain skeptical that communiy groups will be allowed to compete with W3C blue riband technologies |
| 22:12 | <TabAtkins> | s/riband/ribbon/? |
| 22:12 | <karlcow> | zcorpan: business group, this one is less clear to me. |
| 22:12 | <karlcow> | there was 3 competing solutions for SVG ancestors |
| 22:12 | <jgraham> | TabAtkins: No, I think I was right |
| 22:13 | <TabAtkins> | riband Noun: A ribbon |
| 22:13 | <jgraham> | Although wikipedia says that people use "blue ribbon" now |
| 22:13 | <TabAtkins> | Hm, never heard that word before. |
| 22:13 | <jgraham> | But then people now say things like "here here" |
| 22:13 | <jgraham> | Which is just bizarre |
| 22:13 | <TabAtkins> | All the uses of riband I see from a quick search are uk. |
| 22:14 | <TabAtkins> | Idioms and homophones don't mix well, ever. |
| 22:14 | <jgraham> | http://en.wikipedia.org/wiki/Blue_Riband_%28disambiguation%29 |
| 22:14 | <karlcow> | http://www.w3.org/Submission/1998/08/ |
| 22:14 | <karlcow> | http://www.w3.org/Submission/1998/06/ |
| 22:14 | <karlcow> | http://www.w3.org/TR/1998/NOTE-HGML-19980619 |
| 22:15 | <jgraham> | karlcow: There is a difference between an ancestor to a successful technology and a competitor |
| 22:16 | karlcow | doesn't understand how it relates to community groups |
| 22:16 | <jgraham> | TabAtkins: But they use it to mean "listen to this opinion". It is hard for me to understand how it is possible to get confused |
| 22:16 | <karlcow> | ooh diving into the archives, I find again Privacy and Profiling on the Web http://www.w3.org/TR/NOTE-Web-privacy.html |
| 22:17 | <TabAtkins> | jgraham: "hear hear" doesn't necessarily mean "listen to this opinion". It's just a general note of assent, at least to me. So it's easy for me to see how the spelling slips. |
| 22:18 | <TabAtkins> | Plus, the archais use of "hear" as a command to listen to someone else doesn't exactly help. That's why it's an idiom. |
| 22:19 | <jgraham> | So, what I was actually going to say is "it's unclear to me how a group of three search engines constitutes a monopoly" (re: http://www.jenitennison.com/blog/node/157) |
| 22:20 | <jgraham> | In particular the "mono" part |
| 22:20 | <TabAtkins> | Mono-industry, from how I understand the objection. |
| 22:23 | <zcorpan> | Oligopoly |
| 22:24 | <jgraham> | Yes, I think that's what she means. I guess "group of most significant vendors worked together to reach a compromise they could all implement" doesn't sound as scary as "monopoly foists their technology on the world" |
| 22:25 | <jgraham> | Although the first is how most standards organisations work too (although people keep getting upset by that as well) |
| 22:26 | jgraham | notes that he doesn't disagree with much of the blog entry, but thinks it is framed in a very misleading way |
| 22:27 | <zcorpan> | jgraham: just when you thought you were done, Hixie changes the parser :P |
| 22:28 | <Hixie> | blame bz :-P |
| 22:28 | <Hixie> | wait, he can even blame you! |
| 22:28 | <Hixie> | :-P |
| 22:28 | <jgraham> | Wait what? |
| 22:28 | <zcorpan> | i think i suggested this change long ago |
| 22:28 | <jgraham> | I am entirely blameless |
| 22:28 | <Hixie> | no i mean zcorpan |
| 22:28 | <jgraham> | Oh yeah blame zcorpan |
| 22:29 | <jgraham> | He is evil |
| 22:29 | Hixie | would be fine not making this change |
| 22:29 | <zcorpan> | i blame Hixie for not fixing this first time |
| 22:29 | jgraham | thinks this not being fixed straight away would not be the most important bug with Opera and ruby... |
| 22:30 | karlcow | recommends jgraham to send an email to Ian Jacobs |
| 22:30 | <jgraham> | (although I guess it is easy enough to fix) |
| 22:30 | <zcorpan> | jgraham: what? it's VIOLATING the spec |
| 22:31 | <jgraham> | zcorpan: So is not rendering any ruby :) |
| 22:31 | <zcorpan> | jgraham: nah, only if you want the rendering section to apply to you |
| 22:32 | <Hixie> | not rendering a ruby is only violating the spec if you self-identify as a "visual user agent that supports the suggested default rendering" |
| 22:32 | <jgraham> | Not supporting the parser is only violating the spec if you self-identify as a HTML UA |
| 22:32 | jgraham | had this discussion in reverse with Hixie already :) |
| 22:33 | <Hixie> | opera does self-identify as a web browser |
| 22:33 | <zcorpan> | ah, i remember now, this is how the xml guys got away with what the xml spec says |
| 22:33 | <zcorpan> | Hixie: not only! |
| 22:34 | <Dashiva> | Opera only self-identifies as a browser when it isn't parsing |
| 22:35 | <Hixie> | Dashiva: i don't think the spec allows that |
| 22:35 | <zcorpan> | why not? |
| 22:35 | <Dashiva> | Opera doesn't self-identify as the class of implementations that isn't allowed to change self-identification |
| 22:36 | <smaug____> | ooh, I found the place which triggers command's action |
| 22:36 | <jgraham> | I'm reasonably sure that we don't really sel identify as anything |
| 22:36 | <jgraham> | In fact there is probably text somewhre saying that we don't promise to be fit for any purpose |
| 22:36 | <smaug____> | click() handling is still strange though |
| 22:37 | <smaug____> | Hixie: why does click() have different behavior than dispatching a click event manually? |
| 22:38 | <smaug____> | both need to dispatch untrusted events |
| 22:40 | <Hixie> | smaug____: click() is equivalent to dispatching the event manually and then providing a default action |
| 22:41 | <smaug____> | Hixie: but why? Why doesn't dispatching click trigger the default handling (in cases we want to allow that to happen with untrusted events) |
| 22:41 | <Hixie> | smaug____: the default handling is, by definition, the handling that occurs when you get back the result of dispatching the event |
| 22:42 | <smaug____> | yes |
| 22:42 | <smaug____> | well, not results |
| 22:42 | <Hixie> | yes, the results |
| 22:42 | <Hixie> | the return value of dispatchEvent() |
| 22:42 | <smaug____> | default handling is the final step of event dispatch |
| 22:42 | <Hixie> | no |
| 22:42 | <smaug____> | huh |
| 22:43 | <zewt> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dispatching-events |
| 22:45 | <smaug____> | zewt: not sure what that link has to do |
| 22:45 | <zewt> | it, uh, explains event dispatch pretty succinctly |
| 22:45 | <smaug____> | zewt: nothing to do with default handling |
| 22:46 | <zewt> | exactly, default handling is not part of event dispatch :) |
| 22:46 | <Hixie> | default handling is what you do when an event you've dispatched is not cancelled |
| 22:46 | <smaug____> | exactly |
| 22:46 | <smaug____> | well, ok, if it is a script based event one could check the return value of dispatchEvent |
| 22:46 | <zewt> | is what *you* do (the code calling for the dispatch), not what the dispatch itself does |
| 22:47 | <smaug____> | in most common cases, browsers do the default handling, not scripts |
| 22:48 | <Hixie> | sure |
| 22:48 | <Hixie> | still not part of the dispatch :-) |
| 22:48 | <smaug____> | well, it kind of is |
| 22:48 | <Hixie> | in so far as it isn't |
| 22:48 | <Hixie> | :-P |
| 22:48 | <zewt> | let's run in circles some more |
| 22:48 | <smaug____> | since default handling can depend on event target chain |
| 22:49 | <Hixie> | not sure what that means |
| 22:49 | <Hixie> | do you have an example? |
| 22:49 | <smaug____> | you have nested elements, and topmost is <a>. |
| 22:49 | <smaug____> | the event is dispatched to some descendant |
| 22:49 | <smaug____> | but it is the a's default handling which may be triggered |
| 22:50 | <Hixie> | sure, but that's decided before the dispatch is started |
| 22:50 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/complete/content-models.html#interactive-content-0 |
| 22:50 | <Hixie> | it's decided in step 1 |
| 22:50 | <Hixie> | event is dispatched in step 3 |
| 22:50 | smaug____ | needs to look at if webkit's event dispatch has changed, but at least in gecko there is PostHandleEvent phase after actual DOM event dispatch |
| 22:50 | <smaug____> | and webkit used to have it too |
| 22:51 | <Hixie> | browsers do all kinds of weird things |
| 22:52 | <smaug____> | on so do specs :) |
| 22:53 | <smaug____> | s/on/and/ |
| 22:53 | <zcorpan> | which came first, browsers or specs? |
| 22:53 | <smaug____> | depends on the case |
| 22:54 | <zcorpan> | did tim write a spec for html before implementing it? |
| 22:55 | smaug____ | thought the activation handling in HTML was well specified, but isn't sure anymore :/ |
| 22:55 | <zcorpan> | nn |
| 22:55 | <Hixie> | it's well-specified in that it's fully defined, whether it's well-specified in that you agree with it is a different issue :-) |
| 22:55 | <TabAtkins> | Well-specified, but possibly not good-specified. |
| 23:04 | <Hixie> | http://www.w3.org/mid/CCB7E43A-25F8-404F-A4C7-047CCE332CF8⊙wo is ludicrous |
| 23:07 | <TabAtkins> | ...what?! |
| 23:07 | <smaug____> | yeah, webkit has similar internal default handling phase after dom event dispatch as what gecko has |
| 23:08 | <zewt> | isn't that just an implementation detail |
| 23:09 | <smaug____> | it kind of is, but it may affect how click() and default handling should be specified |
| 23:09 | <smaug____> | since in the browsers elements have default handling in them |
| 23:10 | <smaug____> | and that happens as a part of event dispatch |
| 23:10 | <zewt> | but where the default handling happens internally is an implementation detail |
| 23:11 | <smaug____> | zewt: it affects to the behavior of click() vs. manual event dispatching |
| 23:11 | <smaug____> | currently in Gecko click() is basically the same as dispatching click manually |
| 23:12 | <zewt> | i seem to vaguely recall fighting with that at some point |
| 23:13 | <smaug____> | I wonder why the spec is written the way it is |
| 23:13 | <zewt> | which spec? |
| 23:13 | <zewt> | (click() or DOM events) |
| 23:14 | <smaug____> | click() handling |
| 23:14 | <Hixie> | what does it do and what do you want it to do? |
| 23:14 | <smaug____> | so far this hasn't had anything to do with DOM events :) |
| 23:15 | <zewt> | everything about where default handling takes place is related to the event model :) |
| 23:15 | <smaug____> | Hixie: the question is that should the default handling (which is bound to some elements) happen the same way when dispatching a click manually or when calling click() |
| 23:15 | <smaug____> | or that is at least one question |
| 23:16 | <smaug____> | I don't understand why click() should have special powers to trigger default actions |
| 23:16 | <Hixie> | well it's not very interesting if it's just syntactic sugar for two lines of code |
| 23:16 | <smaug____> | (I see click() as a leftover from netscape 2/3) |
| 23:34 | <Hixie> | i wonder if we should drop <time> and instead just have an element like <abbr> whose purpose is specifically to give a machine-readable equivalent |
| 23:34 | <Hixie> | like <abbr> as it was (once?) used in microformats, i mean |
| 23:38 | AryehGregor | has just discovered how insanely awesome Google Voice is |
| 23:38 | <boogyman> | pain! |
| 23:38 | <Hixie> | heycam: just saw in your e-mail that you'd done the patch! looking now |
| 23:38 | <heycam> | Hixie, kk |
| 23:39 | <Hixie> | (i don't read bugmail since i get so much of it) |
| 23:40 | <heycam> | ah |
