| 00:24 | <JonathanNeal> | TabAtkins, you may find this interesting http://sandbox.thewikies.com/html5-wai/ it attempts to hit many birds with one stone; html5, outline, wai, 508, microformat. |
| 00:28 | <TabAtkins> | JonathanNeal: Why are you using <div>s for the main content rather than <article>? |
| 00:28 | <TabAtkins> | Also, role=document is assumed automatically on <body>, so there's no reason to put a wrapper <div> just to get that. |
| 00:29 | <JonathanNeal> | It's there in the event I add an application aside of it. |
| 00:29 | <TabAtkins> | ?_? |
| 00:29 | <JonathanNeal> | say a dockbar on the top, a chatbar on the side, or some other role="application" aside the main document but on the same page. |
| 00:30 | <TabAtkins> | Regardless, the <body> is still a role=document, and I don't think it needs to be repeated on the main page. |
| 00:30 | <TabAtkins> | I assume that anything which isn't explicitly wrapped is considered part of the body's document. |
| 00:32 | <JonathanNeal> | If that was the case, then there would never be a reason to use more than one role per page. |
| 00:32 | <JonathanNeal> | clarify --- role="document" || role="application" |
| 00:33 | <TabAtkins> | I'm not sure what you mean. You just gave a potential reason to use more than one role. You're embedding applications inside a document. |
| 00:33 | <JonathanNeal> | I can see removing it because it is inherited from body (since body is not overwritten) |
| 00:34 | <TabAtkins> | Btw, the lynx viewer link you have gets angry if it sees a referer from another page. |
| 00:34 | <JonathanNeal> | <body><div role="application>dock application</div><div role="document">main document</div><div role="application>chat application</div></body> |
| 00:34 | <JonathanNeal> | I know, I go there and then just re-highlight the addy and return. |
| 00:34 | <TabAtkins> | Kk, just saying. |
| 00:34 | <JonathanNeal> | So ... you're saying that it's unnecessary because in that case ... |
| 00:34 | <JonathanNeal> | <body><div role="application>dock application</div><div>main document</div><div role="application>chat application</div></body> ... is just the same |
| 00:35 | <TabAtkins> | Yeah. |
| 00:35 | <TabAtkins> | I think. |
| 00:35 | TabAtkins | isn't an expert on ARIA, but that seems to make sense. |
| 00:35 | <JonathanNeal> | Yeah, that makes sense to me too, I think you're right. |
| 00:44 | <KaOSoFt> | I'm just a novice but, why <div id="main-content"> and not <section id="main-content">? I'm coding an HTML5 template right now, and I use a <div id="wrap">, but I also (inside the "#wrap") use a <section id="main-content">. |
| 00:45 | <TabAtkins> | I don't see a particularly good reason for either of those <div>s. The whole <div><div><section> structure should be swappable for a single <article> or <section>. |
| 00:47 | <KaOSoFt> | Well, I read somewhere (unfortunately don't remember where) that now with <section> and <article>, <div> had no semantic meaning, that's why I use it as a meaningless container. |
| 00:48 | <KaOSoFt> | Well, while <header> and <footer> should make things "easier", I also have a point of view where they are still <section>s, which means, that I'd do it: <section id="header">, <section id="main-content"> and <section id="footer">, for example. |
| 00:48 | <TabAtkins> | <div> Never had semantics meaning, actually. It was always purely there for the purpose of grouping things to make it easier to throw CSS and JS at the page. |
| 00:48 | <TabAtkins> | Same with <span>. |
| 00:50 | <TabAtkins> | The idea of <section>, <article>, <aside>, etc is that some of those groupings *were* semantics, and commonly expressed by authors (often through #ids on the elements), so we can usefully capture those semantics and allow other technologies to use them. |
| 00:54 | <JonathanNeal> | For me, having a <section id="main-content"> would not be so easy to title. |
| 00:54 | <KaOSoFt> | Like I said, elements like <header> and <footer> are just short-cuts to me. They are indeed <section>s. Oh, well, I could just stay with my idea, and use <section id="header"> and the like, but future-proof machines wouldn't understand my web site as well. |
| 00:54 | <JonathanNeal> | and something like <section id="wrap"> would default the sectioning purpose of <body> |
| 00:55 | <JonathanNeal> | I think there is still room for divs to be organizational for the content, which you could say is semantic. |
| 00:55 | <TabAtkins> | <header> isn't a section, actually, and you don't want it to be - it would scope the headings you put in it to itself, and not let them refer to the outer section you put the <header> in! |
| 00:55 | <JonathanNeal> | Since the requirements and recommendations for sectioning are too strict on <section|article|aside|etc> |
| 00:56 | <KaOSoFt> | TabAtkins- Hmm, yeah, I'm checking the code on your test-site, and it indeed doesn't use <header> as the header of the document. It uses a <div>, and you use <header> to encompass the headings. |
| 00:56 | <TabAtkins> | That's JonathanNeal. ^_^ |
| 00:56 | <KaOSoFt> | Er, yeah, that. |
| 00:56 | <KaOSoFt> | :P |
| 00:56 | <JonathanNeal> | KaOSoFt, yea that's my test site. TabAtkins may not want to be associated with that little nugget of joy. |
| 00:57 | <KaOSoFt> | Hahaha. |
| 00:57 | <KaOSoFt> | God, semantics sometimes can be deceitful. |
| 00:57 | <TabAtkins> | You can use <header> as the header of the site! Nothing wrong with that; in fact, plenty right with it. It's just not a "section", in the way that <section> and <article> and <aside> are. |
| 00:59 | <TabAtkins> | Precisely because "sections" scope the headings inside of them, and you *want* headings inside of <header> to apply to the content outside of <header>. |
| 00:59 | <KaOSoFt> | Where do you take the role from? Is it part of HTML5 spec? |
| 00:59 | <KaOSoFt> | "role=" |
| 00:59 | <JonathanNeal> | <div id="main-document" /> extends body (the scope isn't changed by sectioning content), and there are instances where I will have other applications aside it, like I mentioned earlier. The benefit is that, even in instances where there are NOT applications aside of it, I can keep the div because it doesn't have any meaning. |
| 00:59 | <TabAtkins> | Officially from the ARIA spec, but HTML5 defines how you can use @role on HTML elements. |
| 01:00 | <KaOSoFt> | I see. |
| 01:00 | KaOSoFt | goes to check the ARIA spec |
| 01:01 | <JonathanNeal> | So then it's useful for styling. Giving it the role was to enforce its intended usage, but without the other DIVs it doesn't seem as necessary, and as TabAtkins is pointing out, the document role may already be inherited. |
| 01:06 | <TabAtkins> | KaOSoFt: Basically, ARIA is a way to add additional semantics to documents in ways that the document language doesn't yet allow, so that other types of UAs, like screen readers, can understand what something is. For example, javascript libraries often let you define a slider control, and build it out of several <div>s. You can tell what this is and how to use it by looking at it, but if you were having the page read to you you'd have n |
| 01:07 | <TabAtkins> | A lot of HTML5 elements now carry native semantics that render a lot of ARIA unnecessary, which is a good thing. Frex, <input type=range> should replace many uses for sliders. |
| 01:28 | <KaOSoFt> | So many things to synchronize. :S |
| 01:29 | <KaOSoFt> | Everytime I read about a specification, it makes me wonder how long will it take to really release HTML5. |
| 01:31 | <KaOSoFt> | I mean: |
| 01:31 | <KaOSoFt> | It's like, there are so many things that HTML5 has currently addressed, that every time I see something new (to me), I wonder how long will it take to make it work together, all synchronized. |
| 01:34 | <Hixie> | it's probably a bad sign that having decided i wasn't sure if "punt" meant what i thought it meant, i looked it up on wikitionary, and the only example usage of the word in the sense i meant it is quoting two people i work with. |
| 01:35 | <KaOSoFt> | ._. |
| 01:36 | <KaOSoFt> | Oh, by the way, I've had this inquiry for a while, and I think this channel would be the right place to ask: |
| 01:37 | <gsnedders> | Hixie: Which meaning? |
| 01:38 | <KaOSoFt> | I've always read that we should specify the image height and width in the <img> tag, so browsers render them faster, but is it really "okay"? I mean, if for some reason I change the image, which could possibly change its size, I'd have to also change the HTML file. |
| 01:38 | <TabAtkins> | There's nothing wrong with either way. |
| 01:48 | <Hixie> | gsnedders: not doing it straight away |
| 01:48 | <Hixie> | as in, i think we should punt on doing this for now |
| 01:49 | <KaOSoFt> | Oh, well, time to go home. |
| 01:49 | <KaOSoFt> | Goodnight. |
| 02:36 | <yael_> | hello, can I ask a ARIA related question here? |
| 02:37 | <davidb> | yael: sure, there is also #wai-aria |
| 02:38 | <davidb> | oh sorry that is on w3c |
| 02:41 | <yael_> | I am workin on connecting the progress element to accessibility technology. Since ARIA defines one role for both determinate and indeterminate progress bar, how does the browser convey the difference to the accessibility software? |
| 02:43 | <yael_> | On the mac, it says "9 percent" for indeterminate progress bar, and that is obviously wrong. |
| 02:43 | <Hixie> | if you're implementing the <progress> element in a browser, you wouldn't use ARIA, you'd use the platform-native accessibility APIs |
| 02:43 | <Hixie> | or am i misunderstanding |
| 02:45 | <yael_> | You are right, but I am still defining the role for the progress element , and pass that to the platform API. |
| 02:45 | <othermaciej> | yael_: if you're talking about WebKit, you would want to special case this in the accessibility code |
| 02:45 | <othermaciej> | yael_: we have the ability to represent roles that don't map to an ARIA role |
| 02:46 | <yael_> | othermaciej: Do you have an example? |
| 02:47 | <othermaciej> | yael_: look at the AccessibilityRole enum in AccessibilityObject.h |
| 02:47 | <othermaciej> | yael_: you can add roles to that if you need to |
| 02:47 | <othermaciej> | but it's also worth checking what the mac AX APIs expect for an indeterminate progress bar |
| 02:48 | <yael_> | sounds good, thanks |
| 02:48 | <othermaciej> | yael_: Mac has only one role for progress indicators; you can see the reference for all roles here: http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/Reference/Reference.html#//apple_ref/doc/c_ref/ |
| 02:49 | <othermaciej> | yael_: what you probably need is to expose the right attributes |
| 02:50 | <othermaciej> | yael_: you can see what a native progress bar exposes for role and attributes with Accessibility Verifier.app |
| 02:50 | <othermaciej> | yael_: for both determinate and indeterminate state |
| 02:50 | <othermaciej> | yael_: your goal at least in the Mac accessibility interface should be to replicate that |
| 03:45 | <JonathanNeal> | Hi all! |
| 06:12 | <othermaciej> | hello everyone |
| 06:15 | <JonathanNeal> | hi othermaciej |
| 06:51 | <othermaciej> | Hixie: are you around? |
| 06:52 | <othermaciej> | Hixie: wanted to ask why you went with leading underscore instead of leading hyphen for vendor-specific attributes |
| 06:52 | <othermaciej> | Hixie: so I can appropriately advise people thinking of using vendor-specific attributes |
| 07:19 | <Hixie> | othermaciej: leading hyphen is illformed in xml |
| 07:20 | <othermaciej> | Hixie: stupid bondange&discipline markup language! |
| 07:21 | <Hixie> | *shrug* |
| 07:21 | <Hixie> | i just work with what we have |
| 07:23 | <hsivonen> | :-( crazy volume of email on public-html. Will I miss anything if I mark all as read? |
| 07:23 | <othermaciej> | what's weird is that NAmespaces in XML allows essentially anything |
| 07:23 | <othermaciej> | hsivonen: which thread? |
| 07:24 | <hsivonen> | othermaciej: everything since Friday |
| 07:25 | <othermaciej> | hsivonen: I can summarize for you, since I am crazy enough to read all of it |
| 07:26 | <hsivonen> | Shelley wanted to remove stuff and others disagreed? |
| 07:26 | <othermaciej> | Hixie: superficially, it looks like Namespaces in XML allows leading underscore unless I am reading wrong: 'In XML documents which conform to this specification, element and attribute names MUST match the production for QName and MUST satisfy the "Namespace Constraints".' |
| 07:26 | <othermaciej> | Hixie: or is the prevailing interpretation that you have to match both QName and Name? |
| 07:26 | <othermaciej> | hsivonen: that was a lot of it |
| 07:27 | <othermaciej> | hsivonen: with subthreads on accessibility and control styling |
| 07:27 | <Hixie> | xmlns doesn't change xml syntax |
| 07:27 | <Hixie> | it just adds more constraints |
| 07:27 | <othermaciej> | I thought the post about control styling that I tweeted was marginally interesting |
| 07:27 | <Hixie> | unless you've found a bug in xmlns |
| 07:28 | <hsivonen> | othermaciej: I read the email you tweeted. thanks |
| 07:28 | <Hixie> | QName doesn't match anything Name doesn't match |
| 07:28 | <othermaciej> | Hixie: I am pretty sure the QName production in Namespaces in XML 1.0 (Third Edition) is not a proper subset of the Name production in XML 1.0 (Fifth Edition |
| 07:29 | <Hixie> | sure it is |
| 07:29 | <Hixie> | it's defined in terms of Name in fact |
| 07:29 | <othermaciej> | oh I see |
| 07:29 | <othermaciej> | I failed to comprehend the '-' |
| 07:30 | <Hixie> | there's even a comment explaining it :-P |
| 07:30 | <othermaciej> | yeah, but who has time to read specs :-p |
| 07:30 | <othermaciej> | I don't know if I can bring myself to tell people to make attributes starting with _webkit- |
| 07:30 | <othermaciej> | if I tell them it's for XML compatibility they will just laugh at me |
| 07:31 | <Hixie> | well if it helps, mozilla's been doing it for about a decade now |
| 07:31 | <othermaciej> | hsivonen: other stuff of interest - the lengthy ISSUE-88 (content-language) continues |
| 07:31 | <Hixie> | and fwiw, if this discourages people from making extensions, that's fine too |
| 07:31 | <othermaciej> | hsivonen: we have a possible solution on referencing the IRI spec if Larry ever wakes up |
| 07:31 | <Hixie> | (not so fine if it encourages them to just trample over the language of course) |
| 07:31 | <othermaciej> | Hixie: there are _moz- attributes? |
| 07:32 | <Hixie> | yeah |
| 07:32 | <othermaciej> | example? |
| 07:32 | <othermaciej> | hsivonen: also DanC submitted a very mild proposal for the "resource" vs "resource representation" issue |
| 07:32 | <othermaciej> | and Julian said it would be fine with him to remove the description of @profile from the spec |
| 07:33 | <hsivonen> | In my opinion, _moz attributes shouldn't be exposes as attributes but should be stored on the DOM nodes or maybe CSS frames as private data |
| 07:33 | othermaciej | hopes we can actually resolve some issues maybe |
| 07:33 | <hsivonen> | othermaciej: thanks |
| 07:34 | <hsivonen> | othermaciej: try parsin <keygen> in text/html or some non-trivial MathML in application/xhtml+xml in Firefox and inspect the DOM to see _moz attributes |
| 07:35 | <othermaciej> | hsivonen: I see - so it's Mozilla internal stuff? |
| 07:35 | <othermaciej> | as opposed to extensions anyone is meant to see? |
| 07:36 | <hsivonen> | othermaciej: right (at least for the _moz attributes I have seen) |
| 07:36 | <othermaciej> | I am not sure we store anything like that as DOM attributes in WebKit |
| 07:36 | <othermaciej> | maybe in editing code, though I think that is mostly limited to funky class names |
| 07:37 | <othermaciej> | yeah, just funky class names afaict |
| 07:37 | <Hixie> | othermaciej: the only example i can think of is _moz-unknown which is set on elements the (old?) parser didn't recognise |
| 07:38 | <Hixie> | oh yeah as hsivonen says there's also some _moz stuff around <keygen> |
| 07:38 | <othermaciej> | the parser adding random attributes seems really bad, however they are prefixed :-( |
| 07:38 | <hsivonen> | yes |
| 07:38 | <Hixie> | indeed |
| 07:38 | <Hixie> | i didn't say it was a good idea :-) |
| 07:38 | <Hixie> | just that they have existed |
| 07:39 | <othermaciej> | I get it |
| 07:39 | <othermaciej> | I just cry with sad on the inside |
| 07:39 | <Hixie> | hehe |
| 08:57 | <jgraham> | TabAtkins: If there is some way that I can be in the loop on the testing thing, let me know what it is :) |
| 09:05 | <hsivonen> | wirepair: Yes, I have considered the threat of using validator.nu with show source enabled as an open proxy |
| 09:06 | <hsivonen> | wirepair: a mitigating factor is that the resource being retrieved has to go through the HTML parser or the XML parser without fatal errors |
| 09:07 | <Hixie> | hah |
| 09:07 | <hsivonen> | wirepair: so it's useless as a general purpose proxy for anonymous porn surfers |
| 09:07 | <zcorpan> | so if you don't want your site vulnerable, include start your html page with <head></head><link> |
| 09:08 | <hsivonen> | wirepair: so far, there haven't been problems with people using it as a text-only open proxy |
| 09:08 | <hsivonen> | wirepair: so I haven't tried to make that kind of use harder |
| 09:09 | <hsivonen> | wirepair: after all, the show source feature is pretty useful for its intended purpose |
| 09:10 | <hsivonen> | wirepair: as for 3rd party security, if someone has a vulnerability that can be exploited by cookieless GET from the public network, they have bigger problems than validators |
| 09:37 | <hsivonen> | what was the "subdued errors concept" |
| 09:37 | <hsivonen> | my memory is bad |
| 09:38 | <Hixie> | what we had before we moved to comforming-but-obsolete-and-with-warning |
| 09:39 | <Hixie> | something that's an error but which the validator is expected to collapse into a single statement that "there are also some other less important things to worry about" |
| 09:41 | <othermaciej> | it was "downplayed errors", wasn't it? |
| 09:42 | <hsivonen> | yeah, I thought that was "downplayed errors" |
| 09:45 | <othermaciej> | whatever one names that category, I think collapsing all the notices into a single statement, yet still labeling the document as nonconforming, is the opposite of what is useful for very minor issues |
| 09:51 | <Hixie> | aren't "downplayed" and "subdued" the same thing? |
| 09:51 | <jgraham> | Sigh. The amount of effort that has gone into naming and renaming that categoty of things is so sad |
| 09:51 | <Hixie> | if i said "subdued", i was referring to "downlplayed"; if someone else was, dunno |
| 09:51 | <jgraham> | *category |
| 10:21 | <hsivonen> | Hixie: I see |
| 11:36 | <annevk> | oh fun, maybe <basefont> can be nuked after all |
| 11:49 | <zcorpan> | nuked from dom and parser? |
| 11:49 | <annevk> | not parser |
| 11:50 | <annevk> | since the parser cost is extremely low I don't really care about that |
| 11:55 | <zcorpan> | what's the new information about basefont? |
| 11:58 | <Lachy> | Which browser's support basefont? Is it just IE? |
| 11:59 | <Lachy> | and do you have information about it being removed from IE9 or something? |
| 11:59 | <jgraham> | I guess Mozilla just removed it |
| 11:59 | <annevk> | zcorpan, sicking wrote a patch for Gecko |
| 12:00 | <Lachy> | ah, that explains why Minefield isn't supporting it now. |
| 12:02 | <annevk> | not really, it hasn't landed |
| 12:02 | <zcorpan> | i wonder what ie9 does with basefont |
| 12:02 | <zcorpan> | Lachy: mozilla hasn't supported rendering for basefont before |
| 12:03 | <zcorpan> | Lachy: but has had HTMLBaseFontElement or whatever |
| 13:05 | <hsivonen> | Lachy: IIRC, no one got around to implementing <basefont> in Gecko in the first place |
| 13:28 | <annevk> | would be fun to transition text-align |
| 14:00 | <gsnedders> | Is it bad I can't help but think of XML when othermaciej says "this change proposal is well-formed" |
| 14:01 | <Dashiva> | Yes |
| 14:01 | <Dashiva> | So is a non-well-formed change proposal still a change proposal, or is it just mislabeled text? |
| 14:01 | <jgraham> | Nah, it just doesn't exist, by definition |
| 14:02 | <jgraham> | A theoretical impossibility |
| 14:35 | <zcorpan> | where's the webaddress spec? |
| 14:35 | zcorpan | needs the 'resolve an address' algorithm |
| 14:36 | <gsnedders> | You don't get no stinkin' address. |
| 14:36 | <zcorpan> | :'( |
| 14:36 | jgraham | wonders if that algorithm has actually been written yet |
| 14:36 | <zcorpan> | i thought it was in the webaddress spec |
| 14:37 | <zcorpan> | http://www.w3.org/html/wg/href/draft |
| 14:37 | <jgraham> | I mean it *did* exist but then people decided it wasn't good enough just to have all the useful information, there also had to be fights about where the useful information lived |
| 14:37 | <jgraham> | and some information got lost in the fights |
| 14:37 | <jgraham> | But maybe not that |
| 16:15 | <TabAtkins> | jgraham: Join the public-test-infra list. We're stealing it for our purposes. |
| 16:16 | <gsnedders> | TabAtkins: People and their mailing lists |
| 16:16 | <jgraham> | Yay, mailing lists! |
| 17:24 | <JonathanNeal> | hi all! |
| 17:24 | <TabAtkins> | yo |
| 17:25 | <TabAtkins> | Oh man, anyone in MV that wants brownies should come by my office. |
| 17:26 | <JonathanNeal> | Mission Viejo? |
| 17:27 | <TabAtkins> | Sure. It'll be a drive, but if you're still welcome to come by my office. |
| 17:36 | <KaOSoFt> | Good morning. |
| 17:49 | <KaOSoFt> | :o |
| 17:49 | <KaOSoFt> | Google already supports Microdata. |
| 18:01 | <KaOSoFt> | In HTML5, can <img> be used outside of <figure>? Like: http://pastebin.com/BzcDZqct |
| 18:01 | <TabAtkins> | Yeah, you can still use <img> wherever you want. |
| 18:26 | <KaOSoFt> | While what I'm about to say might be a taboo, have you people made a poll with the users on this channel about what they're currently using, be it RDFa or Microdata? |
| 18:26 | <TabAtkins> | Is it important to do so? |
| 18:27 | <KaOSoFt> | Statistics are always important, whether you take them into account or not. |
| 18:27 | <TabAtkins> | Statistics of a random chat room probably aren't. ^_^ Usage on the web is. |
| 18:28 | <KaOSoFt> | Well, the poll would be about people using it. |
| 18:28 | <KaOSoFt> | ._. |
| 18:30 | <JonathanNeal> | KaOSoFt, you didn't even mention microformatting. |
| 18:30 | <JonathanNeal> | That's like not including Google :) |
| 18:30 | <TabAtkins> | Microformats are already part of HTML, though. We're talking *dedicated* metadata embedding formats. |
| 18:30 | <KaOSoFt> | Well, to be "impartial", let's include Microformatting, though I don't like it that much. |
| 18:30 | <JonathanNeal> | TabAtkins, well maybe everyone is okay with that. |
| 18:31 | <KaOSoFt> | Besides, I guess usage shows a bigger RDFa user-base than Microdata, given their age. |
| 18:32 | <JonathanNeal> | Say 1000 people use one of those three; 300 use microdata, 200 use RDFa, and 500 use microformatting --- disregarding microformatting is strange --- because they're all trying to accomplish the same functionality. |
| 18:32 | <JonathanNeal> | It's not like comparing people that don't do anything to people that do something --- you should try to include all popular "something"s. |
| 18:33 | <KaOSoFt> | Hmm... though it's an example, you mention at least 300 people using Microdata. Has user-base really grown that much? |
| 18:33 | <KaOSoFt> | I mean, in general. |
| 18:33 | <JonathanNeal> | The internet is SERIOUS BUSINESS KaOSoFt! |
| 18:37 | <TabAtkins> | In any case, Microformats are not defined by their embedding. They're a structure to apply to data. They happened to use an embedding method built around existing HTML4 syntax, because that's what was available at the time, but writing an hcard in Microdata or RDFa is still using Microformats. |
| 18:37 | <KaOSoFt> | I guess in the end it's better to have multiple "supported" options, than to have one unsupported. |
| 18:38 | <KaOSoFt> | That's kind of why I don't like Microformats. |
| 18:42 | <JonathanNeal> | It's kinda what the class attribute was designed to do. |
| 18:43 | <JonathanNeal> | Not that I'm against Microdata or RDFa, even though they kill unicorns. |
| 18:43 | <TabAtkins> | Well, yes and no. Class isn't necessarily supposed to be communicating anything meaningful to the outside world. It's meant for private communication between the page author and their tools. |
| 18:44 | <JonathanNeal> | RDFa has nicer documention and adoption than Microdata IMHO. |
| 18:46 | <TabAtkins> | While I, on the other hand, find Microdata's overall syntax and data model to be immensely simpler and easier to write and read. |
| 18:48 | <JonathanNeal> | TabAtkins, I bet I would feel the same way if the documentation wasn't such a unrainbow. |
| 19:11 | <KaOSoFt> | Oh, damn, wait... if not even Internet Explorer recognizes HTML5 elements (<header>, <section>, etc.), how can I make print stylesheets work? :o |
| 19:12 | <TabAtkins> | The IE printing problem is a hard one. If print stylesheets working in IE is important to you, don't use HTML5 yet. |
| 19:13 | <KaOSoFt> | Internet Explorer 8* |
| 19:14 | <KaOSoFt> | Yeah. It's not a problem for MY website, but if I were to ever code a website for someone else, I guess I'd have to switch back to <div>. |
| 19:14 | <TabAtkins> | I think that most people don't actually care how websites print, so you're probably okay. |
| 19:15 | <TabAtkins> | IE can handle the new elements just fine on the screen, with the createElement hack. |
| 19:16 | <KaOSoFt> | Yeah. |
| 19:16 | <KaOSoFt> | HTML5Shiv was a life-saver for a lot of people. |
| 19:16 | <JonathanNeal> | Shiv the printer! |
| 19:16 | <TabAtkins> | AFAIK, no one's figured out how to. ;_; |
| 19:16 | <JonathanNeal> | http://sandbox.thewikies.com/html5-experiments/phase-01.html http://sandbox.thewikies.com/html5-experiments/phase-02.html |
| 19:18 | <JonathanNeal> | Any blogs giving an example of how the html5 ie printing problem works? |
| 19:18 | <JonathanNeal> | Maybe I can look into it. |
| 19:20 | <KaOSoFt> | JonathanNeal- None that I know of. :'( |
| 19:21 | <KaOSoFt> | JonathanNeal- I'm going to (try to) check all your SandBox examples. http://sandbox.thewikies.com/ |
| 19:21 | <KaOSoFt> | :D |
| 19:21 | <JonathanNeal> | Don't judge me, brah. |
| 19:27 | <KaOSoFt> | JonathanNeal- Phase 02 images don't work. |
| 19:27 | <KaOSoFt> | In Experiments, I mean. |
| 19:29 | <KaOSoFt> | Is this alright? |
| 19:29 | <KaOSoFt> | article, aside, figure, footer, header,hgroup, menu, nav, section {display: block;} |
| 19:29 | <KaOSoFt> | Am I missing anything? |
| 19:30 | <TabAtkins> | Check JonathanNeal's HTML default stylesheet. |
| 19:33 | <KaOSoFt> | Hmm... where? I don't find it in the sandbox folder, not in the document's own CSS. |
| 19:35 | <KaOSoFt> | nor* |
| 19:35 | <TabAtkins> | I didn't bookmark it last time I saw it; ask JonathanNeal |
| 19:36 | <JonathanNeal> | You mean http://www.iecss.com/whatwg.css ? |
| 19:36 | <TabAtkins> | Yeah |
| 19:37 | <KaOSoFt> | Hmm, it's a reset stylesheet. Good, let's check it out. |
| 19:37 | <KaOSoFt> | Thanks. |
| 19:40 | <KaOSoFt> | It specifies everything. |
| 19:40 | <KaOSoFt> | -_- |
| 19:41 | <TabAtkins> | Yes, it's meant to be an example of what an actual UA stylesheet for HTML5 could look like. |
| 19:41 | <KaOSoFt> | UA means a browser? |
| 19:42 | <TabAtkins> | Yeah. User Agent. |
| 19:42 | <KaOSoFt> | User Agent, oh, yes. |
| 19:42 | <TabAtkins> | In this context, browser, but it can mean lots of things. |
| 19:42 | <KaOSoFt> | Yeah, I know. |
| 19:42 | <miketaylr> | should that include stuff like :valid, :invalid, :out-of-range, etc? |
| 19:43 | <miketaylr> | or would that be handled elsewhere? |
| 19:43 | <TabAtkins> | HTML5 doesn't specify any default renderings for those. |
| 19:43 | miketaylr | doesn't know |
| 19:43 | <miketaylr> | ah. |
| 19:43 | <KaOSoFt> | Hmm... and while this should provide a good example, is that CSS publicized so that UA developers know of it? |
| 19:43 | <miketaylr> | yeah, gotcha TabAtkins |
| 19:43 | <TabAtkins> | KaOSoFt: It's just a distillation of what HTML5 says, in a perhaps-more-understandable and centralized format. |
| 20:13 | <dglazkov> | TabAtkins has the best brownies |
| 20:28 | <JonathanNeal> | I found a way to work around the HTML5 printing bug in IE |
| 20:28 | <TabAtkins> | paul_irish: ^^^ |
| 20:36 | <miketaylr> | JonathanNeal: how!?!??! |
| 20:36 | <TabAtkins> | Gah, I knew I wanted to tell someone else, but I forgot who. Sorry, miketaylr. |
| 20:36 | <miketaylr> | haha no worries :) |
| 20:36 | <miketaylr> | all of my css expression hack attempts failed |
| 20:38 | <KaOSoFt> | JonathanNeal- Link, or it doesn't exist...! |
| 20:38 | <KaOSoFt> | ._. |
| 20:45 | <JonathanNeal> | Okay. |
| 20:46 | <miketaylr> | JonathanNeal: i'm super curious :) |
| 20:48 | <KaOSoFt> | http://blog.whatwg.org/usability-testing-html5 |
| 20:48 | <KaOSoFt> | Interesting conclusions. |
| 21:00 | <paul_irish> | JonathanNeal: is it using behavior: ? |
| 21:08 | <JonathanNeal> | no |
| 21:10 | <Hixie> | KaOSoFt: microdata is very new, i wouldn't expect many people to be using it today |
| 21:11 | <Hixie> | KaOSoFt: however, it has the support of some pretty big companies, e.g. google added support for it recently |
| 21:11 | <TabAtkins> | I just now wrote a quick tutorial on Microdata this is hopefully informative and accessible. Review comments welcome: http://www.xanthir.com/document/document.php?id=a3c2c6bb66f089ef0cec212c7409c83b7f4ab3af217f1cc4bb664a135a7d172c364c625be73b7da5750fd01bed1ea739cb7fa61de8fc7f46d01334df1164d70e |
| 21:12 | <TabAtkins> | Or, less ridiculous, http://www.xanthir.com/:gg5 |
| 21:20 | <KaOSoFt> | JonathanNeal- HTML5 + Internet Explorer = Print? :'( |
| 21:21 | <paul_irish> | he's got a solution. sounds really promising. it's coming... :) |
| 21:21 | <KaOSoFt> | I need to set up a blog. That solution will be my first entry on it. |
| 21:21 | <KaOSoFt> | ^_^ |
| 21:22 | <paul_irish> | do it! |
| 21:26 | <KaOSoFt> | Arggh, I guess WordPress is the fastest solution. |
| 21:28 | <JonathanNeal> | thanks paul_irish, I'll have something up today. |
| 21:29 | <KaOSoFt> | My first blog entry will make me rich...! |
| 21:29 | <KaOSoFt> | :D |
| 21:37 | <AryehGregor> | TabAtkins, is the author of document.php a big fan of GUIDs and thinks it's easier to use SHA512 than figure out MAC addresses or such? Or maybe they just want really secure content-addressable storage? |
| 21:48 | <TabAtkins_> | AryehGregor: Whirlpool hash, actually. |
| 21:49 | <TabAtkins_> | And I'm the author. Woo! |
| 21:52 | <AryehGregor> | TabAtkins_, so why are you using 512-bit hashes for id's? |
| 21:53 | <Hixie> | he's VERY prolific |
| 21:53 | <jgraham> | Y'know I was just about to ask that |
| 21:54 | <jgraham> | hint: if it's longer than the hash you get when you check it into your VCS, it's too long :) |
| 21:54 | <TabAtkins_> | Because shrug, that's why. |
| 21:54 | <Hixie> | to use up the entire address space over 100 years of blogging, you'd have to blog at a rate of 4.2 x 10^144 Hz |
| 21:55 | <AryehGregor> | jgraham, well, git uses SHA1, which isn't advisable if you want actual security . . . |
| 21:55 | <Hixie> | that is an INSANE frequency |
| 21:55 | <AryehGregor> | Hixie, but only the square root of that to have a high chance of collision, right? That's much more reasonable. |
| 21:56 | <Hixie> | um, even to avoid a collision, if you were to have that frequency as EM waves, it'd still be 40 orders of magnitude narrower wavelength than the width of an atom |
| 21:57 | <AryehGregor> | Well, so you can just write a lot of blog posts in parallel. |
| 21:57 | <AryehGregor> | A million monkeys and all. Or 10^60 monkeys, whatever it takes. |
| 21:57 | <TabAtkins_> | Dude, I coded my document writer in like 10 minutes. I had just used whirlpool for something else, because it's fun, so it was on my mind. |
| 21:57 | <AryehGregor> | (I'm not sure there's enough mass in the observable universe to create 10^60 monkeys.) |
| 21:57 | <TabAtkins_> | They'd have to be very small monkey, but you could. |
| 21:58 | <Hixie> | very small |
| 21:58 | <Hixie> | there's only ~10^80 atoms in the visible universe |
| 21:58 | <Hixie> | and most of that is hydrogen |
| 21:58 | <Hixie> | not so useful for making monkeys |
| 21:59 | <Philip`> | http://www.guzer.com/pictures/very-small-monkey.jpg ? |
| 22:00 | <Philip`> | You could use the hydrogen to make inflatable monkeys |
| 22:00 | <Hixie> | there's about 10^27 atoms in that monkey assuming he's about 1kg |
| 22:01 | <AryehGregor> | That looks like a heck of a lot less than 1 kg. |
| 22:01 | <AryehGregor> | Hmm, maybe not so much less. |
| 22:01 | <Hixie> | so that's 10^53 monkeys max |
| 22:01 | <TabAtkins_> | Yes, by "very small" I meant "microscopic". |
| 22:01 | <AryehGregor> | I dunno, I'm not a primatologist. |
| 22:01 | <AryehGregor> | TabAtkins_, it has to be big enough to type blog posts at random, otherwise it won't work. |
| 22:02 | <TabAtkins_> | By the time I'm converting the mass of the universe into monkeys, I think I can devise alternate typing methods. |
| 22:02 | <Philip`> | How much entropy does a typical monkey contain? |
| 22:02 | <Hixie> | also alternate hashing methods |
| 22:03 | <AryehGregor> | Yeah, it'd probably be relatively easy to switch to a 1024-bit hash, if you have the resources to make that many monkeys. |
| 22:07 | <jgraham> | TabAtkins_: You know when the TAG said URLs were opaque identifiers you weren't supposed to take it as a commandment to make them as opaque as possible |
| 22:08 | <TabAtkins_> | WELL MAYBE THEY SHOULDN'T HAVE SUGGESTED IT THEN. |
| 22:08 | TabAtkins_ | sulks. |
| 22:08 | <Dashiva> | jgraham: How do you know we weren't supposed to? |
| 22:10 | <AryehGregor> | jgraham, that's not as opaque as possible. It has "document.php" in it. |
| 22:12 | <TabAtkins_> | AryehGregor: That's why I provided the more opaque but less entropic link /:gg5 |
| 22:12 | <AryehGregor> | "less entropic"? |
| 22:12 | <TabAtkins_> | lower entropy |
| 22:13 | <TabAtkins_> | i was constrained in my wording by parallelism. |
| 22:13 | <TabAtkins_> | more/less |
| 22:14 | <AryehGregor> | How is it lower-entropy? |
| 22:14 | <TabAtkins_> | Less possible states. |
| 22:20 | <AryehGregor> | What's your definition of microstates and macrostates here? |
| 22:20 | <JonathanNeal> | Back |
| 22:20 | TabAtkins_ | waves hands wildly. |
| 22:20 | <AryehGregor> | I mean, you say a macrostate is low-entropy if there are few microstates corresponding to it. |
| 22:21 | <TabAtkins_> | I really don't have a sufficient background to properly defend my statement. |
| 22:24 | <JonathanNeal> | TabAtkins_ I'll try to have that html5 ie print thing shared soon enough. |
| 22:24 | <JonathanNeal> | I hope I don't come across like a dick, I just want to give something that has had some testing. |
| 22:24 | <TabAtkins_> | Man, whatever, dick. |
| 22:24 | TabAtkins_ | pfft. |
| 22:27 | <Hixie> | ok, finally finished dealing with e-mail |
| 22:27 | <Hixie> | now to find some food |
| 22:27 | <Hixie> | bbiab |
| 22:28 | <JonathanNeal> | :| |
| 22:31 | <gsnedders> | TabAtkins_: Bitch. |
| 22:31 | TabAtkins_ | takes it to the street. |
| 22:55 | <KaOSoFt> | JonathanNeal- Internet Explorer Collection could help you in testing: http://finalbuilds.edskes.net/iecollection.htm |
| 22:58 | <KaOSoFt> | In fact, I had not tried it on Wine. Perhaps I should... |
| 22:58 | KaOSoFt | is downloading the IE Collection to try it on Ubuntu |
| 23:00 | <paul_irish> | dunno about through wine, but the spoon.net browsers are the most solid (aside from the VPC vm's) alternate IE versions there are |
| 23:01 | <KaOSoFt> | I think I had visited that site before, but it didn't have all those programs. |
| 23:02 | <KaOSoFt> | Hmm... I don't see IE. |
| 23:04 | <paul_irish> | http://spoon.net/Browsers/ |
| 23:06 | <KaOSoFt> | Ohh, I see, since I'm on Linux it says IE is currently unavailable on my device, which explains why I didn't see it in the Browsers section. |
| 23:07 | <KaOSoFt> | In fact, ALL of it says my device is not supported. :'( |
| 23:08 | <KaOSoFt> | The a element without an href attribute now represents a "placeholder link". It can also contain flow content rather than being restricted to phrase content. |
| 23:08 | <KaOSoFt> | What does "placeholder link" mean? |
| 23:11 | <JonathanNeal> | IT WORKS!!!!!! |
| 23:12 | <KaOSoFt> | Link, or it doesn't exist...! |
| 23:12 | <KaOSoFt> | ._. |
| 23:13 | <KaOSoFt> | "dir has been obsoleted in favor of ul". Does this include dir as in 'dir="ltr"'? |
| 23:15 | <jgraham> | KaOSoFt: A placeholder link is typically something that a script will come and fill in with a href value later on |
| 23:17 | <KaOSoFt> | Hmm, I see. I didn't use those because it wasn't unobtrusive, but if they are to be allowed now, all hail HTML% |
| 23:17 | <KaOSoFt> | HTML5!* |
| 23:24 | <annevk> | wow TabAtkins; URL fail :p |
| 23:25 | <annevk> | Hixie's URLs are not that great, but you are pushing it |
| 23:26 | <TabAtkins_> | KaOSoFt: That passage is talking about <dir>, not @dir. Completely different things. |
| 23:28 | <TabAtkins_> | annevk: I'll note that the urls are much better for me. The one I share is specifically made to be unguessable. I just go a little overboard with it. ^_^ |
| 23:29 | <jgraham> | TabAtkins_: Why do you want an unguessable URL? |
| 23:30 | <jgraham> | I mean isn't it easier just to set up authentication? |
| 23:30 | <TabAtkins_> | jgraham: No. |
| 23:31 | <jgraham> | It seems easier to leak a URL |
| 23:32 | <jgraham> | (becasue you give it to someone, they link to it, google finds it, and you have lost) |
| 23:32 | <jgraham> | (whereas if you give them a username / password they implicitly understand it is supposed to be private) |
| 23:34 | <TabAtkins_> | That's fine. Once I've given it to someone, I obviously want it to be findable. |
| 23:35 | <jgraham> | I have occasionally given out links to people that I did not want to be public (or, sometimes, they did not want to be public) |
| 23:35 | Philip` | once saw a site that encrypted a password plus today's date rounded to 6 months, to generate a URL for a private page |
| 23:36 | <Philip`> | and if you got the wrong password then you'd get the wrong URL, and if you had the URL then it'd only be valid for 6 months |
| 23:36 | <Philip`> | but I could find a few of those 6-month URLs since they'd leaked out onto Google |
| 23:37 | <Philip`> | and (since the encryption algorithm wasn't very good) use them to work out the password |
| 23:37 | <Philip`> | which then allowed access to the most recent page |
| 23:37 | <jgraham> | So I don't really buy the idea that everything shared is implicitly public |
| 23:38 | <TabAtkins_> | jgraham: You don't have to. I was expressing my own feelings on content that I share. ^_^ |
| 23:39 | <jgraham> | TabAtkins_: Just don't be surprised if this happens every time you share a link :) |
| 23:39 | <TabAtkins_> | Philip`: Was it actually encrypted, or just hashed? |
| 23:39 | <jgraham> | Where by "this" I mean an inquisition about your URL scheme |
| 23:39 | <TabAtkins_> | Also, that seems pretty bad, since you have to prevent password collisions, and thus leak information about other pages on the system. |
| 23:40 | <TabAtkins_> | jgraham: That's why I need to remember to share my shorturls instead. ^_^ |
| 23:40 | <TabAtkins_> | Also, why I need to finally sit down and build myself a proper blogging platform out of the tools I have lying around. |
| 23:40 | <Philip`> | TabAtkins_: It was some rubbish JS hash-like algorithm |
| 23:41 | <TabAtkins_> | Philip`: Ah, homerolled crypto. Nice. |
| 23:41 | <jgraham> | It is long past bedtime |
| 23:41 | <jgraham> | Goodnight |
| 23:42 | <KaOSoFt> | Goodnight. |
| 23:45 | <annevk> | jgraham, good point |
| 23:46 | <annevk> | I'm failing with bedtimes |
| 23:47 | <annevk> | Well, I value fun over sleep, which is something that does not scale, but I've yet to come to terms with that |
| 23:49 | <TabAtkins> | annevk: Surefile solution: get married. |
| 23:50 | <annevk> | I don't think I'm ready for that yet :) |
| 23:52 | <Hixie> | TabAtkins: how does getting married help with that problem? |
| 23:52 | <TabAtkins> | Well, it makes sure I get to bed before midnight every day. |
| 23:53 | <TabAtkins> | If Rachel's gone for some reason, my bedtimes hover around 3 or 4am |
| 23:53 | <Hixie> | i just ended up making carey go to bed around 4am... |
| 23:54 | <JonathanNeal> | Ready? |
