| 00:01 | <AryehGregor> | Apparently "w" doesn't, except in loanwords. Wikipedia doesn't say for "ch". |
| 00:01 | <AryehGregor> | (I mean, in Norwegian.) |
| 00:02 | <AryehGregor> | The name is evidently Polish. My analysis is vindicated! |
| 00:02 | <AryehGregor> | (I'm terrible at accents, though) |
| 00:02 | <TabAtkins> | Had I ever paid enough attention to remembeer maciej's last name, I'd have said polish or czech too. |
| 00:03 | <AryehGregor> | I didn't remember it, but I remembered that it looked Eastern European. |
| 00:03 | <AryehGregor> | I agree that the first name is less clear. |
| 00:03 | <TabAtkins> | I could easily imagine a norwegian named maciej. |
| 00:04 | <TabAtkins> | Though perhaps a norwegian couldn't. ^_^ |
| 00:05 | <AryehGregor> | The final J looks wrong to me for Norwegian. |
| 00:06 | <AryehGregor> | Also, do they use C? |
| 00:06 | <AryehGregor> | Apparently they don't use C. |
| 00:06 | <TabAtkins> | Maybe? |
| 00:06 | <TabAtkins> | Okay. |
| 00:15 | <takkaria> | 'ch' exists in Swedish |
| 00:16 | <AryehGregor> | Not Norwegian, though, it seems? |
| 00:16 | <takkaria> | well, in Swedish, it only occurs in certain situations and even then it seems to vary by dialect just how you pronounce it |
| 00:17 | <takkaria> | Linköping, where I am ATM, gets pronounced variously as "lin-chur-ping", "link-shop-ping" or someting sort of between the two |
| 00:25 | <takkaria> | and yeah, Maciej's name is polish |
| 00:26 | othermaciej | loves all the theorizing about the hypothetically possible ethnic origins of my name |
| 00:30 | <annevk3> | http://www.rudibela.com/blog/web-design/feeter-movement is funny |
| 00:30 | <annevk3> | found in comments on Zeldman's blog |
| 00:31 | <othermaciej> | these posts from web design big-shots are interesting reading |
| 00:31 | <TabAtkins> | annevk3: heh, funny. |
| 00:32 | <annevk3> | oh wow, Raph (Dutch gov) found another way how we violate WCAG2: http://www.w3.org/TR/WCAG20/#ensure-compat-parses |
| 00:33 | <annevk3> | but that feels like a bug in WCAG2 to me, given that it undermines a perfectly valid HTML4 feature |
| 00:34 | <othermaciej> | wait, is the claim that HTML5 violates WCAG2 by allowing some open and close tags to be omitted like HTML4 did? |
| 00:34 | <annevk3> | http://www.zeldman.com/2009/08/31/loving-html5/#comment-47961 |
| 00:34 | <annevk3> | it seems a perfectly reasonable claim to me |
| 00:34 | <annevk3> | though it also applies to HTML4 and it should be noted that WCAG doesn't deal with <img/> syntax |
| 00:36 | <othermaciej> | it doesn't seem to deal with <img> syntax either - it's nonconforming to give <img> an end tag in HTML syntax |
| 00:37 | <othermaciej> | I'm not sure allowing something that WCAG disallows, is automatically a WCAG conflict, in the same way as disallowing something that WCAG requires |
| 00:38 | <othermaciej> | but I also think this WCAG requirement is questionable, because it doesn't seem to help accessibility or interop at all |
| 00:40 | <alkarin> | regarding to the sample company web page presented at whatwg.org, where you see a footer defined within the FOOTER, I see more navigation links - akin, the NAV group. |
| 00:41 | <TabAtkins> | alkarin: where is this presented? |
| 00:41 | <alkarin> | I still have doubts over this issue if sophisticating the standards would help, say, web usage of the disabled people .. |
| 00:41 | <annevk3> | othermaciej, it seems to me this is just a bug (and also WCAG overstepping its scope) |
| 00:42 | <TabAtkins> | alkarin: While that's not necessarily a <nav> (it may not be primary navigation), it certainly *could* be. I agree that the current <footer> definition is confusing when it disallows that. |
| 00:45 | <alkarin> | where we, ourselves are quite disabled, 1. inside the tag junk, 2. inside the market, among the other individuals who are reckless and disregarding any type of rules that are imposed or proposed on them - while BROWSERS tolerating their disregard and award their so-called SEO efforts! |
| 00:46 | <alkarin> | Besides, in my humble opinion, a standization should not include, even in its draft stage at a demo. page, a de-standardized recognition of BROWSER names :*( |
| 00:47 | <othermaciej> | annevk3: I agree it's a bug in WCAG, if that's what you mean |
| 00:47 | <alkarin> | I believe *strictly* sticking to the standards and still smiling and being nice at the others is not a good thing |
| 00:47 | <TabAtkins> | alkarin: I don't understand what you mean? The conditional comment at the top of the page to trigger the ie-shim? |
| 00:48 | <othermaciej> | annevk3: I don't think it's a conflict, because it's ok for WCAG to require things that HTML merely allows |
| 00:48 | <othermaciej> | annevk3: if all WCAG requirements had to be HTML requirements then WCAG would be redundant |
| 00:49 | <TabAtkins> | alkarin: We live in the real world, unfortunately, not the magic world where everything works perfectly everywhere. IE requires a quick js shim to recognize the new elements correctly. We could run that unconditionally, but that would just be wasteful. |
| 00:49 | <alkarin> | if we are to impose a force, or show the path to, again let's say, Microsoft, then there must be somebody who is controlling its implementations |
| 00:50 | <TabAtkins> | It's not some sort of pandering to bad browsers - it's hacking around the fact that old IEs predated HTML5, and so didn't have the ability to support them. Firefox 2 had similar problems, but they weren't really fixable. |
| 00:50 | <alkarin> | notice TabAtkins I partially agree with you - but we "all" are in real world so one must hang a notice on the wall about how to sit how stand and how to talk .. you got what I mean? |
| 00:52 | <TabAtkins> | Yes, that's the standard. That doesn't mean you ignore old browsers when they can be easily hacked into working. Again, IE6 and IE7 aren't *willfully* violating the spec - they were created before HTML5 ever existed, and so never knew that the new elements were going to be around. |
| 00:52 | <alkarin> | and that "notice" is the standards, etiquette, rules, code of behaviours and "mark-up" coding |
| 00:53 | <alkarin> | dear tabatkins .. before Microsoft decided to involve in browsers, I was building web pages - reading the latest HTML specifications ... then the browser wars begun, around 2000, we were in dark ages |
| 00:53 | <TabAtkins> | And what does that have to do with IE6's lack of support for <section>? |
| 00:54 | <alkarin> | IE6 is under Microsoft's responsibility - at least - it should be |
| 00:54 | <alkarin> | I should learn to ignore it, If I want to continue |
| 00:55 | <AryehGregor> | The browser wars started well before 2000. |
| 00:55 | <alkarin> | people changing their mobile devices once in every two years - remember what was the name of the operating system you once had in your old old nokia |
| 00:56 | <alkarin> | nope .. you threw it away, you bought a new one. |
| 00:56 | <jcranmer> | my PDA was a iPaq, so it had Windows Mobile 5 |
| 00:56 | <TabAtkins> | alkarin: Still not sure what that has to do with IE6 not supporting <section>. I can't change the fact that people still use IE6. |
| 00:56 | <jcranmer> | before that, I was in position in a Palm Pilot |
| 00:56 | <jcranmer> | s/position in/possession of/ |
| 00:57 | <AryehGregor> | I've never had a cell phone. I did have a PDA, and it was a Palm, so it presumably ran Palm OS. |
| 00:57 | <jcranmer> | I want to say version 3? |
| 00:58 | <jcranmer> | maybe 4 |
| 00:58 | <jcranmer> | ah yes, 4 |
| 00:58 | <TabAtkins> | alkarin: Ignoring current browsers is part of why XHTML2 died. You couldn't render an XHTML2 document properly in *any* browser. That was actually intentional for some reason. |
| 00:59 | <alkarin> | Hey folks .. this is a good web page please look at it, about mobile web building - http://www.bbc.co.uk/mobile/web/versions.shtml |
| 00:59 | <jcranmer> | not quite sure what OS versions have to do with anything |
| 01:00 | <alkarin> | There you will see that, or some of you have already been practicing that you ought to imploy different standards <of not only mark-up> for various displaying-media |
| 01:01 | <alkarin> | which is, I believe, contradictory to what Tim Berner Lee had suggested at the first standardization < still looking for his link at TED.com, a recent speech of him about the future of world wide web > |
| 01:02 | <TabAtkins> | alkarin: That's not something we should do in general. Legacy smartphones were limited in what they could download and display well. It *did* make sense to create separate versions of pages for them, because they simply couldn't handle a full webpage. |
| 01:02 | <TabAtkins> | Modern smartphones can easily handle modern webpages, and they'll continue to be able to. It no longer makes much sense to design for the mobile space. |
| 01:03 | <tantek> | mostly agreed TabAtkins |
| 01:03 | <tantek> | not necessarily "easily" |
| 01:03 | <AryehGregor> | TabAtkins, it makes a heck of a lot of sense to design for small screens. |
| 01:03 | <AryehGregor> | Which is more or less equivalent to mobile. |
| 01:03 | <TabAtkins> | tantek, point granted. It will get easier, though. |
| 01:03 | <tantek> | numerous / many / (most?) "modern" webpages include huge amounts of AJAXy script that fails on mobile |
| 01:03 | <tantek> | for lots of reasons |
| 01:03 | <tantek> | including failure to separate the device dependent aspects |
| 01:04 | <tantek> | assuming a pointer, click, hover etc. |
| 01:04 | <tantek> | and coincidentally, all those assumptions break accessibility as well |
| 01:04 | <tantek> | including the "javascript is always there" assumption |
| 01:04 | <tantek> | which also breaks search engines |
| 01:04 | <TabAtkins> | alkarin: A phone is *very rarely* used for 8 years. 8-year old browsers *are* still used. You can try to draw a parallel, but I can just point to the real world and prove you wrong. |
| 01:04 | <tantek> | *well designed* modern webpages work just fine on modern smartphones |
| 01:05 | <alkarin> | javascript breaking SE? I wonder how |
| 01:05 | <TabAtkins> | tantek: point |
| 01:05 | <tantek> | alkarin - javascript included content is invisible / not seen by search engines |
| 01:05 | <tantek> | e.g. every Disqus comment on numerous blogs |
| 01:05 | <TabAtkins> | tantek: not necessarily. I think google might run js at least somewhat now? I'm not sure. At least they *plan* to. |
| 01:06 | <tantek> | (nevermind whether such comments are worth indexing, that's a separate matter ;) ) |
| 01:06 | <tantek> | TabAtkins - and Technorati ran some limited javascript "inspection" (would not say "run" or "execution") for blogroll links etc. |
| 01:06 | <tantek> | but in general, it's a good assumption that any content created/produced by javascript is invisible to search engines |
| 01:06 | <alkarin> | The term Javascript can be a propriatery but it is one of dealing with the document objects model - so this is not a shame, this is not out of HTML which is also a part of the same DOM |
| 01:07 | <alkarin> | one 'way' of dealing with .. sorry |
| 01:07 | <tantek> | any feature that depends on javascript likely breaks in search engines, at least some smartphones, and accessibility |
| 01:08 | <alkarin> | do the cellphones not implement a dom tree? then CSS would have been impossible to render |
| 01:08 | <TabAtkins> | tantek: to be fair, that's partially an observation born out of limited memory/complexity of such devices. It's gradually making more and more sense to handle js in those sorts of things. |
| 01:08 | <tantek> | or I should say, *likely* breaks accessibility. it *is* possible to author accessible javascript, but it is rare that you find web developers that know how |
| 01:08 | <tantek> | TabAtkins - not just limited mem/cpu - but also input modes |
| 01:09 | <tantek> | can't assume hover/active states etc. |
| 01:09 | <TabAtkins> | True, input modes are an issue. |
| 01:09 | <tantek> | this is not a problem that moore's law will solve |
| 01:09 | <TabAtkins> | Would likely be best to create a set of input-agnostic events that we can hook into reliably. |
| 01:09 | <tantek> | make your content declarative in your HTML, or expect that your content will be broken in many user agents |
| 01:10 | <tantek> | browsers, devices etc. |
| 01:10 | <tantek> | just because you implement a DOM tree does not mean you implement a script *execution* environment |
| 01:10 | <tantek> | or the same "level" of environment |
| 01:11 | <AryehGregor> | Aren't the events deliberately defined vaguely so that unconventional input devices could be used? |
| 01:11 | <tantek> | you can implement a DOM tree without any execution |
| 01:11 | alkarin | concurs. |
| 01:11 | <AryehGregor> | That is, a screen reader could define some non-mouse-related way to "click" on something. |
| 01:11 | <TabAtkins> | Aryeh: presumably yeah, but we still end up having to listen for, say, both a click and a keypress. |
| 01:12 | <alkarin> | a screen reader will possibly look for skipping the part where I defined as FOOTER, however, in my own understanding of elements, I might have declared them inside ..err.. header ... side bar .. virtually anywhere |
| 01:13 | <TabAtkins> | alkarin: does that cause a problem? |
| 01:14 | <alkarin> | so at a blah-blah old cell-phone my navbar inside header would be practically at the footer and sidebar was set to display:none .. and so on. |
| 01:16 | <alkarin> | yes tabatkins, it causes a problem, a problem of WHO are within this environment of standards.. is that only us? like the real merchants paying taxes but on the streets, you can go by selling your stuff w/out pay |
| 01:16 | <alkarin> | if you are not to touch your lovely IE6's |
| 01:16 | <TabAtkins> | alkarin: I have no idea what that has to do with the placement of <footer> |
| 01:16 | <TabAtkins> | Unrelated: Holy crap, guys, this is awesome - http://www.longestpoemintheworld.com/ |
| 01:17 | <alkarin> | If someone is imaginative enough to create a FOOTER then why some others are set to back this project? Look at what the people still using out there .. |
| 01:17 | <AryehGregor> | TabAtkins, I expected something like "It's the Song that Never Ends" repeated infinitely as you scroll down, using JS, but that's way more amusing. |
| 01:18 | <TabAtkins> | alkarin: I still don't know what you're talking about. How is IE6 setting this back? |
| 01:20 | <TabAtkins> | AryehGregor: I'm having fun reciting it out loud. ^_^ |
| 01:21 | <AryehGregor> | It even makes sure the line lengths match up. |
| 01:21 | <AryehGregor> | Some of the lines don't really scan, but I suppose that's unavoidable. |
| 01:21 | <TabAtkins> | Yeah, it counts syllables. Awesome. ^_^ |
| 01:21 | <TabAtkins> | Yeah, but surprisingly few. |
| 01:22 | <alkarin> | Using microformats and help it spreading is a great idea since it has its own promotions / rewards within it. An efficient and less-resource spending way of data sharing which had been targetted with world wide web. |
| 01:23 | <alkarin> | But as to designing with a revised standards, while still Google do not disqualify any violations and regard the pages with link-forges, and Microsoft or others don't stop saying "but we have another idea" sort of things ... I dont call it a standard at all since this way was NOT targetted with world wide web |
| 01:23 | <alkarin> | in its beginning |
| 01:24 | <alkarin> | you can't wear on a yellow jacket at the military just b/c that's your most lovely suit. |
| 01:25 | <alkarin> | but 400 years ago, it was possible. |
| 01:26 | <alkarin> | Now we have rules - then somebody has to be kind enough to back these efforts on solid grounds, and disqualify any kind of violations to it. |
| 01:26 | <AryehGregor> | I'm not really following you. The WHATWG can't force anyone to follow its standards, and making standards no one will follow is pointless. |
| 01:27 | <alkarin> | then what good are you, what good in saying this is a standard in the first place? |
| 01:27 | <AryehGregor> | So that implementers can make sure they all implement the same thing, which they all want to implement. |
| 01:27 | <alkarin> | and yes, I didn't say this should be part of the responsibility of a single work group |
| 01:27 | <AryehGregor> | Rather than implementing the same thing in incompatible ways. |
| 01:28 | <AryehGregor> | Unless you're going to have it mandated by law that everyone has to listen to the W3C, there's no point in talking about forcing anyone to do anything. |
| 01:28 | <alkarin> | Right - and following that idea, Microsoft implements its own version of HTML rendering while others did theirs |
| 01:28 | <AryehGregor> | Yes, that's part of what HTML 5 is meant to put an end to. |
| 01:29 | <AryehGregor> | Make a single, detailed, consistent, featureful version of HTML that everyone is happy to implement. |
| 01:29 | <AryehGregor> | If any major vendor flat-out refuses to implement a feature, it's removed from the spec. That's the policy. |
| 01:29 | <alkarin> | then we should be ready to wave a bye-bye and smile at incopatible applications |
| 01:29 | <AryehGregor> | I'm not sure what you mean. |
| 01:30 | <alkarin> | I don't want to put those <!--- if MSIE --> exceptions |
| 01:30 | <alkarin> | http://www.whatwg.org/demos/company-home/ |
| 01:31 | <alkarin> | if they see ugly - I should be less worried by my lack of efficient presentation - I must be " compansated " |
| 01:31 | <AryehGregor> | Then don't put them there. |
| 01:31 | <AryehGregor> | Feel free. |
| 01:31 | <AryehGregor> | Of course, then IE will break, but that's your call, if it's your website. |
| 01:40 | tantek | catches up after being disconnected |
| 01:42 | <tantek> | AryehGregor - re: "Aren't the events deliberately defined vaguely so that unconventional input devices could be used?" - only *if* authors understand the deliberate vagueness/abstraction and code accordingly. more often they assume the device capabilities of their laptop |
| 01:42 | <tantek> | or maybe their iPhone if you're lucky :) |
| 01:43 | <AryehGregor> | What's an example of how this would fail in real life? |
| 01:49 | <tantek> | depends on the vague/abstract events |
| 01:49 | alkarin | asks to tantek: in 10 years of time what expectations do you have in your minds, from an obtimist's point of view |
| 01:50 | <alkarin> | regarding to the mark-up standards and data sharing, microformats.. |
| 01:52 | <alkarin> | :me is AFK - eating time before fasting |
| 02:02 | <tantek> | AryehGregor - nearly any site that uses AJAX to handle clicks to show more content etc. |
| 02:02 | <AryehGregor> | I mean, what specific problems are caused in practice? Don't all devices allow the user to trigger click events somehow? |
| 02:03 | <AryehGregor> | And if not, shouldn't they? |
| 02:04 | <tantek> | sometimes such sites are coded to handle clicks only when in the "hover" state |
| 02:04 | <tantek> | because of course a hover precedes a click right? ;) |
| 02:05 | <tantek> | oh and note - not all devices have an arbitrary "click" at this x-y location |
| 02:05 | <tantek> | e.g WebTV |
| 02:05 | <tantek> | e.g. BlackBerry |
| 02:05 | <tantek> | so yes, this breaks in multiple ways for different devices |
| 02:08 | <alkarin> | thanks for the answer - by the way, why are we not talking about HTML itself, AJAX is just an insertion of external HTML segment.. |
| 02:09 | <alkarin> | the breaking of web pages are related with how they are implementing things inside their httpd headers - this isn't an HTML matter |
| 02:09 | <alkarin> | and neither a javascript matter |
| 02:10 | <alkarin> | even a flash interface imploying the same principals will again break the page integrity |
| 02:13 | <AryehGregor> | He was answering me, I think, not you. |
| 02:13 | <alkarin> | moreover, the device users won't upgrade their software - they renew their entire platforms - so they'll stay updated even web-wise. But how about IE5 users at an old Apple Mac |
| 02:15 | <alkarin> | HTML5 or 6 will be no more than a common practice among the "scholars" unless there is a flow created inside the market < browser industry, search engines, blog softwares, editors etc > |
| 02:16 | <alkarin> | since you can always live by with your good old tables - feel free to abuse resources, just who cares |
| 02:17 | <alkarin> | in my country, people are making " CSS LOOKING web pages " .. or " contemporary " so they say .. according to them, this kind of design is just a " fashion " |
| 02:19 | <alkarin> | and no customers are even bothering themselves of learning what they were.. is this the standards we have been fighting for .. nearly 20 years? |
| 02:20 | <alkarin> | We need usability guidilines, serious support on official grounds so the obsolote and resource wasting world wide web sources would be " disqualified " in one way or another |
| 02:22 | <alkarin> | We are defining a new band for Television signals, and once this is implemented by stations, no incompatible receivers will be able to catch it |
| 02:34 | <MikeSmith> | tantek: ping |
| 02:36 | <tantek> | MikeSmith: http://tantek.pbworks.com/CommunicationProtocols#Dontpresencequery |
| 09:27 | <jgraham> | I really don't understand the whole "html5 super friends" thing. Is it so hard to give feedback without having to make up an exclusive club with a silly name? I /know/ it is supposed to be funny and I /know/ a bunch of the people involved are nice, sincere, people but it rubs me up the wrong way something chronic |
| 09:30 | <othermaciej> | it does not bother me |
| 09:31 | <jgraham> | You have to say that you're the chair ;) |
| 09:31 | <othermaciej> | some smart and widely respected people in the world of Web design gave their general endorsement to HTML5, and some useful specific feedback |
| 09:31 | <jgraham> | I agree the _feedback_ is useful |
| 09:31 | <othermaciej> | some of those same people were kind of hostile to the HTML5 effort before that |
| 09:32 | <othermaciej> | so if getting together in person and making up a silly name for their club helped them do that, then more power to them |
| 09:32 | <jgraham> | It's the way it is _presented_ that bothers me |
| 09:33 | <jgraham> | If they had just got together and said "a few of us had an informal meeting and here is some feedback" it would have been wonderful |
| 09:33 | <hsivonen> | jgraham: In general, the open letter format bothers me, but I'm not going to complain about that in this case. Instead, I'm going to take it as positive feedback. |
| 09:34 | <othermaciej> | collective open letters can be an unhealthy communication pattern sometimes, but not in this case afaict |
| 09:34 | <erlehmann> | damn super friends ! they hate mah <dialog> … |
| 09:35 | <othermaciej> | I also appreciate their general statement of support |
| 09:35 | <jgraham> | I should stress again that it is only the self-aggrandisment inherent in the presentation that bothers me, not the content |
| 09:36 | <othermaciej> | the people involved clearly think they are important in the world of Web design |
| 09:37 | <othermaciej> | since so many people read their blogs and books, and pay to hear them speak, they are right about being important in a sense |
| 09:39 | <othermaciej> | I do prefer people who come off more humble, but I have to admit to occasional self-importance myself |
| 09:39 | <Dashiva> | I wonder how many subscribers public-html would have if it was open for subscribers |
| 09:39 | <othermaciej> | for example, I have great respect for people who have done a lot of the grunt work that went into HTML5 without seeking a lot of name recognition |
| 09:41 | <othermaciej> | Dashiva: it's nearly open with just a few hoops to jump through |
| 09:43 | <Dashiva> | I imagine there are people who just want to read. Even if the hoops are easy, maybe you don't consider yourself worthy. |
| 09:44 | <othermaciej> | it would surely have more subscribers if there were fewer hoops |
| 09:50 | <annevk2> | I thought it was funny |
| 10:07 | <annevk2> | hmm, a couple of detailed questions did more good to ARIA than LC review |
| 10:08 | <othermaciej> | is ARIA being updated? |
| 10:08 | <annevk2> | http://lists.w3.org/Archives/Public/public-html/2009Aug/1472.html suggests it is |
| 10:09 | <annevk2> | probably another LC round too then |
| 10:12 | <othermaciej> | yeah I saw that email |
| 10:13 | <othermaciej> | it makes me happy that the PFWG folks were willing to move on host language semantics (even if it took a long time and then discussion in a telecon) |
| 10:13 | <othermaciej> | and I'm happy that Hixie put a first cut of ARIA integration in the spec, even though he didn't think he had quite all the data he needed |
| 10:13 | <Hixie> | i didn't |
| 10:13 | <Hixie> | see the list of questions i sent out |
| 10:13 | <Hixie> | i still don't |
| 10:13 | <othermaciej> | I know you didn't |
| 10:13 | <Hixie> | as it stands we might have to take it out, in fact |
| 10:14 | <Hixie> | due to lack of completeness |
| 10:14 | <othermaciej> | but now we have that list of questions and before we didn't |
| 10:14 | <Hixie> | yes we did |
| 10:14 | <Hixie> | it's basically the same questions they've been asked many times before |
| 10:14 | <Hixie> | hsivonen wrote similar questions literally years ago |
| 10:15 | <othermaciej> | if he already asked every single question you did, then I'll eat some crow |
| 10:15 | <annevk2> | be careful there :) |
| 10:15 | <othermaciej> | even so, it's good that this time they are actually paying attention |
| 10:16 | <othermaciej> | I think some of your questions have the premise that every element with native semantics needs to map to an existing ARIA role |
| 10:16 | <annevk2> | integrating it definitely helps in moving forward I think |
| 10:16 | <annevk2> | not everyone had an idea of how it would look like I suppose |
| 10:16 | <othermaciej> | that doesn't seem right to me |
| 10:17 | <othermaciej> | role="fileinput" would be useless on a random element, so <input type="file"> should just have its own unique accessibility behavior that doesn't map to an ARIA role |
| 10:17 | <Hixie> | paying attention? |
| 10:17 | <Hixie> | i've received not even an acknowledgement of my questions |
| 10:18 | <Hixie> | i actually don't think it makes sense to have default roles |
| 10:18 | <Hixie> | but that's what they said we should do |
| 10:20 | <othermaciej> | I think it is useful to give the correspondence in cases where an element's accessibility presentation should be basically the same as an ARIA role |
| 10:21 | <othermaciej> | but it would be good to explicitly make room for elements that don't match any existing ARIA role, but nonetheless don't make sense to assign to a different role |
| 10:23 | <Hixie> | well i'll basically just do whatever they suggest, assuming they ever get around to suggesting something |
| 10:24 | <annevk2> | I actually thought the plan would be that someone defined an abstract accessibility API that we'd map elements against |
| 10:24 | <othermaciej> | they like to discuss things a lot |
| 10:24 | <annevk2> | And that the ARIA implementation requirements would also map against that abstract API |
| 10:24 | <othermaciej> | annevk2: that seems like it would be hard |
| 10:24 | <annevk2> | And the document defining the abstract API defines how it maps against the various accessibility APIs around |
| 10:25 | <Hixie> | annevk2: that would be much better, but frankly i don't know that we need to define the mapping explicitly at all. |
| 10:25 | <annevk2> | Hixie, not surprisingly there's issues for interop here too |
| 10:27 | <othermaciej> | I'm not sure a strict mapping to accessibility APIs makes sense, because it would make it impossible to put any novel and clever heuristics on the UA side instead of the AT side |
| 10:27 | <Hixie> | exactly |
| 10:27 | <othermaciej> | with WebKit+VoiceOver, a lot of the smarts are on the UA side |
| 10:27 | <Hixie> | it's UI |
| 10:27 | <Hixie> | that's why i was surprised to hear they wanted us to define a mapping |
| 10:27 | <Hixie> | but i'm no accessibility expert |
| 10:28 | <othermaciej> | and for people using screen readers or the like, innovation in presenting content well is more important than getting substantially the same experience in different products |
| 10:28 | <othermaciej> | because so much of the content wasn't properly designed, and certainly wasn't properly tested for that kind of use |
| 10:32 | <annevk2> | hmm, certainly an interesting perspective |
| 10:47 | <hsivonen> | Hixie: In my thinking, "strong native semantic" didn't imply that the native semantic has to match an ARIA role |
| 10:48 | <Hixie> | i was basing what i wrote on what the wg said |
| 10:48 | <Hixie> | or rather |
| 10:48 | <Hixie> | on what i was told the wg would say |
| 10:48 | <Hixie> | since apparently we're not allowed to actually see what the wg will say until they're ready to say it all at once |
| 10:54 | <annevk2> | there must be Member-only records |
| 10:55 | <annevk2> | but then those cannot be shared so maybe that does not help much |
| 10:59 | <Hixie> | http://damowmow.com/playground/microdata/001/ is some of the material i'm putting together for the usability study |
| 11:02 | <Philip`> | Why does Gmail always say "Warning: This message may not be from whom it claims to be. Beware of following any links in it or of providing the sender with any personal information." when people post to the WHATWG list from @google.com addresses? |
| 11:05 | <hsivonen> | Philip`: maybe Google has had issues with fraudsters impersonating Google staff and they can't themselves distinguish staff from fraustrers algorithmically when the message has done a trip through a list server |
| 11:10 | <annevk2> | Hixie, the study is an attempt at finding out what authors find the most convenient syntax? |
| 11:10 | <Hixie> | yeah |
| 11:11 | <Philip`> | hsivonen: If that was a problem, automatically sending all mail from Google staff into the spam folder (unless the user has a filter set up to explicitly keep list messages out of spam) still doesn't seem like a good solution |
| 11:13 | <takkaria> | hmm, Apple has added closures to C |
| 11:18 | Philip` | wonders how many people writing C don't care about portability (and about non-standard extensions) |
| 11:19 | annevk2 | wonders when people will complain about the spec name change |
| 11:22 | <takkaria> | annevk2: which spec? |
| 11:24 | <annevk2> | HTML5? |
| 11:26 | <adactio> | annevk2: I welcome the clarification. |
| 11:26 | takkaria | did not realise HTML5 had changed name recently |
| 11:26 | <annevk2> | apparently it's obscure enough :) |
| 11:27 | <hsivonen> | annevk2: ooh. even the W3C copy changed. Daring. |
| 11:27 | <hsivonen> | has the wikitruth been updated accordingly? |
| 11:27 | <annevk2> | no, that reminded me actually |
| 11:30 | <annevk2> | adactio, I'll give you hint: whitespace |
| 11:30 | <adactio> | annevk2: I don't need a hint. I was saying "I welcome the clarification" of having one way of referring to the spec (HTML5) instead of two (HTML5 and HTML 5). |
| 11:31 | <annevk2> | adactio, sorry |
| 11:32 | <annevk2> | in retrospect I'm not sure how I did not get that |
| 11:34 | <beowulf> | what was wrong with html 5? |
| 11:37 | <hsivonen> | beowulf: "html" and "5" tokenize separately on Google |
| 11:39 | <karlcow> | html5 decision made for SEO… sirenes de la renommée |
| 11:39 | <Philip`> | beowulf: The problem was the possibility of believing there was a difference between "HTML5" and "HTML 5" |
| 11:39 | <Philip`> | and the confusion caused by that |
| 11:40 | <beowulf> | hsivonen: does that have practical implications? |
| 11:41 | <annevk2> | hsivonen, I think consistency was the reason |
| 11:41 | <Philip`> | See http://www.zeldman.com/2009/08/31/loving-html5/ |
| 11:41 | <beowulf> | Philip`: ah, cool |
| 11:42 | <hsivonen> | beowulf: "html5" gives more useful results on Google |
| 11:42 | <karlcow> | http://www.zeldman.com/superfriends/ mwaarf :) at least a lot of humour :) cool |
| 11:43 | <karlcow> | http://www.zeldman.com/superfriends/guide/ |
| 11:45 | karlcow | loves it: <cite>@t</cite> <q>Plato used shadows of sock puppets.</q> |
| 12:06 | <adactio> | annevk2: Fancy doing a search and replace on the "Differences from HTML 4" and "FAQ" documents to change HTML 5 to HTML5? ;-) |
| 12:08 | <annevk2> | I'll see what I can do |
| 12:11 | <beowulf> | i think dialog is a fine element, but it should use <ul> or <ol> |
| 12:16 | <erlehmann> | beowulf, i am using dialog for markup, and the term:definition thingy comes handy |
| 12:16 | <erlehmann> | guess what happens when several people say the same thing ? |
| 12:16 | <erlehmann> | can't do that with simple lists |
| 12:17 | <beowulf> | erlehmann: explain? |
| 12:18 | <beowulf> | erlehmann: how do you markup a new participant in the conversation? do you close out the dl? |
| 12:18 | <erlehmann> | <dt>Name</dt> ? |
| 12:19 | <beowulf> | erlehmann: that doesn't tell me if Name just joined or was there from the start |
| 12:20 | <erlehmann> | beowulf, i believe stating who is actually there is outside of scope for <dialog> |
| 12:20 | <beowulf> | erlehmann: i think that makes it pretty useless... |
| 12:20 | <erlehmann> | beowulf, useless ? why that? |
| 12:20 | <annevk2> | the FAQ doesn't mention Web Workers at all |
| 12:20 | <erlehmann> | i am actually using <dialog> |
| 12:21 | <erlehmann> | beowulf, one of the good things is that rendering in legacy browsers works nice with <dl>s |
| 12:21 | <beowulf> | erlehmann: most common chat log form indicate joins and parts in the log |
| 12:22 | <erlehmann> | besides, html 4.01 states: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. |
| 12:22 | <beowulf> | and dl styling isn't the most enjoyable thing in the world, but perhaps that's not an issu |
| 12:22 | <erlehmann> | its not an issue, i got it covered. its comparable in difficulty to form styling |
| 12:22 | <beowulf> | erlehmann: this is html5 though, isn't it? |
| 12:23 | <erlehmann> | beowulf, i want to say there is a precedent set for using DT and DD. |
| 12:23 | <erlehmann> | beowulf, read http://blog.dieweltistgarnichtso.net/interview-moot-of-4chan-part-1 |
| 12:24 | <erlehmann> | beowulf, then tell me what exactly you would change in the markup. |
| 12:25 | <hsivonen> | erlehmann: does that format work nicely in the small screen mode in Opera? |
| 12:25 | <beowulf> | erlehmann: that's a pretty straighforward dialog, no-one dropped out, no-one joined late, no net-split, etc |
| 12:25 | <annevk2> | someone interested in fixing the FAQ for Web Workers? |
| 12:25 | annevk2 | just fixed the naming issue plus some editorial cleanup |
| 12:25 | <erlehmann> | hsivonen, the sidebar is a bit messed up on small resolutions, but opera mobile should render it just fine |
| 12:26 | erlehmann | is testing on his android |
| 12:26 | <beowulf> | erlehmann: also, dt's don't render well on low end devices such as mobiles |
| 12:26 | <beowulf> | *dl's |
| 12:26 | <erlehmann> | beowulf, is that so. provide proof. |
| 12:27 | <beowulf> | erlehmann: how much proof do you want? i can screen grab a few of the usual suspects ... |
| 12:27 | <erlehmann> | do it. webkit mobile is fine btw |
| 12:28 | beowulf | hasn't done this in a while... |
| 12:35 | <beowulf> | erlehmann: it'll take me a while to get screen grabs of dl's on small screen devices, in the mean time though it wasn't a major concern with dl in dialog |
| 12:48 | <Lachy_> | Hixie, yt? |
| 13:00 | <beowulf> | erlehmann: fwiw, this is how i marked up our internal irc logs in work, i added microdata just to play with it http://carisenda.com/sandbox/chatlogs/ |
| 13:01 | <annevk2> | hsivonen, but how? |
| 13:01 | <beowulf> | if dialog only permitted <dl> i'd just drop the surrounding <dialog> |
| 13:01 | <beowulf> | (it's based on krijnh's logs) |
| 13:01 | <annevk2> | hsivonen, you want to relate various pieces of data with content |
| 13:01 | <krijnh> | -_- |
| 13:02 | <erlehmann> | beowulf, so much DOM. it kills teh firebug ! |
| 13:02 | <annevk2> | hsivonen, Microdata is perfect for relating various pieces of data |
| 13:02 | <annevk2> | hsivonen, but then cannot handle content |
| 13:03 | <krijnh> | beowulf: you should base it on http://projectcerbera.com/!dev/irc-logs/day :) |
| 13:04 | <erlehmann> | beowulf, looks nice, but still, no semantic markup. |
| 13:04 | <beowulf> | erlehmann: eh?? |
| 13:04 | <beowulf> | krijnh: nice :) |
| 13:04 | <erlehmann> | beowulf, are you counting on overloading the class attribute ? |
| 13:05 | <beowulf> | erlehmann: define overloading |
| 13:05 | <annevk2> | beowulf, why use both classes and microdata? |
| 13:06 | <beowulf> | annevk2: i added microdata later, laziness then took over |
| 13:07 | <annevk2> | if microdata is a success we should probably introduce some cool selectors for it |
| 13:07 | <annevk2> | it has a nice DOM API after all |
| 13:17 | <jgraham> | Aren't selectors generally harder to add than DOM APIs because they need more special code and are more performance sensitive? |
| 13:19 | <jgraham> | (not that I have anything in particular against microdata selectors but there are a lot of problems at the moment where "add more selectors / pseudoelements" seems to be the solution everyone is talking about but no one is implementing) |
| 13:23 | <annevk2> | WebKit added lots of pseudo-elements |
| 13:24 | <annevk2> | pseudo-elements are generally harder though but I think that is mostly because the underlying implementation for the ones introduced so far is different |
| 13:25 | <annevk2> | if we have a bunch of new pseudo-elements that map to well-defined pseudo-boxes it should probably be easier (though getting form controls styleable(sp?) might not be) |
| 14:22 | <Binarytales> | Are there any good write-ups or resources on the issues surrounding <time> especially arguments for the current behaviour? |
| 14:40 | <TabAtkins> | Binarytales: What part of the current behavior don't you like? |
| 14:42 | <Binarytales> | I wouldn't say I either like or dislike it. I've read various snippits arguing for fuzzy and ancient dates which kind of makes sense but I want to know the reasoning behind the current behaviour of only allowing "modern" and complete dates as all I seem to be able to find is "well that's how it is now" |
| 14:43 | <Binarytales> | I guess I'm still trying to understand the issue |
| 14:43 | <TabAtkins> | Ah, ok. I can distill the mailing list explanations down for you, though I can't point to any particular writeups. |
| 14:44 | <TabAtkins> | Basically, calendars are fucked up. The Gregorian calendar that the entire world uses now was invented in its current form only a few hundred years ago, and was only *fully* adopted in the early 20th century (I think Russia was the last to adopt it). |
| 14:44 | <zcorpan> | Binarytales: maybe http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html |
| 14:44 | <Binarytales> | yeah I tried the mailing list but my maillist-search-fu is weak :( |
| 14:44 | <TabAtkins> | It's easy to pinpoint a date after the Gregorian calendar has been established, but before that it's somewhat difficult, and becomes more so the further back you go. This is called the "proleptic" Gregorian calendar, by the way. |
| 14:45 | <TabAtkins> | By the time you hit somewhere around 0 you're running into serious accuracy issues, where for many things it's very difficult or impossible to pin down the *exact* proleptic Gregorian day that a date in an ancient calendar translates to. |
| 14:46 | <Binarytales> | so when someone says "1st May 978" they basically mean that's the closest estimation of that date relative to the current date? |
| 14:46 | zcorpan | tries http://www.google.se/search?q=site%3Alists.w3.org+time-element |
| 14:46 | <TabAtkins> | However, <time> still goes ahead and allows years down to 0, just because why the hell not. |
| 14:46 | <TabAtkins> | BinaryTales: Yeah. There's always some legacy calendar with an exact date that the historian is trying to translate into our current calendar. |
| 14:47 | <TabAtkins> | So, allowing negative years would make the parser slightly more complicated, and you're already at the point where <time> is losing most to all of its value, so the spec just straight disallows it. |
| 14:52 | <Binarytales> | Why just straight out disallow it though? Why can't the parser just say "Hey, there is a time here but I don't understand it, someone else can figure it out?" |
| 14:52 | <TabAtkins> | You can totally put a negative year there if you want. You'll just be nonconforming. |
| 14:54 | <Binarytales> | There are gonna be a lot of authors that will want to put nonconforming dates in <time> - so doesn't it come back to the whole "what the point in writing fiction" thing. Why not provide a nicer way of handling fuzzy dates? |
| 14:55 | <zcorpan> | because no-one has explained what the use case is with fuzzy dates |
| 14:55 | <TabAtkins> | The argument is that fuzzy dates aren't very machine-useful anyway, so just don't use <time> to mark them up. |
| 14:56 | <zcorpan> | s/fuzzy dates/fuzzy dates marked up with an element/ |
| 15:13 | <jgraham> | For the things that people typically talk about "a museum wants to mark up dates in a webpage about a collection of artifacts" you are probably going to need the full power of microdata to do anything useful anyway |
| 15:15 | <TabAtkins> | And if you're using full Microdata, you can just embed the calendar in there too. There's all sorts of craziness around ancient dates that you might usefully want to represent, that should be out-of-scope for <time>. |
| 15:28 | <_h_> | Not all fuzzy dates are historical. Flickr for example lets you put in approximate dates to photos you've taken. Has there been any consideration to perhaps allowing an attribute describing accuracy? exact could be implied; circa for fuzzy; incomplete for when the author knows the year for sure but not the rest...? |
| 15:33 | <hsivonen> | _h_: but what's the use case for making the Flickr dates machine-readable as part of microdata or microformats? |
| 15:41 | <_h_> | hsivonen: mostly related to search - being able to search for content attached to a date specified by the author. fuzzy dates can still be useful - ask an historian who has searched for information about an event "near the turn of the century" :) |
| 15:43 | <_h_> | a fuzzy/circa date doesn't need to specify the margin for error; search engines could provide searches with a tolerance. "search for content from this specific, confirmed date" vs. "search for this date with 10 year tolerance". |
| 15:45 | <hsivonen> | http://www.html-5.com/ |
| 15:47 | <AryehGregor> | Has anyone given thought to making sure there are good-quality sane HTML5 tutorials out there to hopefully preempt the inevitable mounds of complete trash that will arise as public awareness grows? |
| 15:48 | <AryehGregor> | Oh, well, I guess if there are lots of people wanting to make tutorials then we're accomplishing something anyway. ;) |
| 15:49 | <annevk3> | AryehGregor, there have been various ideas floating around but nothing really took of |
| 15:49 | <annevk3> | e.g. at some point I launched wiki.html5.org |
| 15:50 | <annevk3> | and the plan was to have a page for each element, etc. |
| 15:50 | <mwunsch> | i own html-5.org and html-five.org |
| 15:50 | <mwunsch> | planning on writing something there |
| 15:50 | <_h_> | annevk3: perhaps some benevolent browser company will put together an extensive web curriculum and could add html5 to that.... ;) |
| 15:50 | <mwunsch> | just haven't gotten around to it yet :-\ |
| 15:51 | <annevk3> | _h_, yeah, who knows :) |
| 15:51 | <beowulf> | i thought about a version of the spec that linked to good examples for each section, or some way of making that automatic, or something |
| 15:51 | <hsivonen> | html-5.com is quoted as a source in Wikipedia |
| 15:52 | <AryehGregor> | What page? |
| 15:52 | <hsivonen> | AryehGregor: http://en.wikipedia.org/wiki/Document_Type_Declaration |
| 15:53 | <TabAtkins> | Augh, jeez. 1995 called. It wants its webdesigners back. |
| 15:53 | <annevk3> | <!DOCTYPE HTML:html> ? |
| 15:54 | <TabAtkins> | I've... never seeen that before. |
| 15:54 | <TabAtkins> | Think it's just some crazy author making shit up. |
| 15:55 | <Dashiva> | As opposed to the rest of the internet? :) |
| 15:56 | <TabAtkins> | Gah, I'm gonna go edit that. The entire subsection about "the doctype name must exactly match the root element name" is just plain wrong. |
| 15:56 | <annevk3> | there's also this openweb.org effort |
| 15:56 | <annevk3> | maybe when that gets of the ground it will provide good documentation |
| 15:56 | <hsivonen> | annevk3: not found |
| 15:58 | <AryehGregor> | hsivonen, it doesn't anymore. :) |
| 15:58 | <hsivonen> | AryehGregor: cool |
| 15:58 | <AryehGregor> | (Not a [[WP:RS|reliable source]]!) |
| 15:58 | <hsivonen> | thanks |
| 15:58 | <TabAtkins> | Also, article editted to remove stupid reference to HTML:html |
| 15:59 | <annevk3> | hsivonen, see Google Groups |
| 16:09 | <TabAtkins> | Hmm, I wish there was some way to say "keep your spot in the flow, but act like you're an abspos and sit on top of your neighbors". I'm implementing expandy-menus, and have to do it by keeping a container element around and absposing the children. |
| 16:19 | <mwunsch> | Would footnotes of an article be appropriately marked up in an <aside> ? |
| 16:20 | <AryehGregor> | That doesn't seem right to me. |
| 16:20 | <mwunsch> | Or would it be more appropriate to mark them up as a <section> |
| 16:20 | <mwunsch> | ? |
| 16:21 | <jgraham> | mwunsch: http://www.whatwg.org/specs/web-apps/current-work/#footnotes |
| 16:21 | <TabAtkins> | If I included a footnote inline, it would totally be as <aside>. |
| 16:22 | <TabAtkins> | It satisfies the related-but-tangential smell test. |
| 16:23 | <mwunsch> | jgraham: Thank you. |
| 16:23 | <mwunsch> | I was about to quote the spec, but my browser is hanging... |
| 16:24 | <TabAtkins> | If I collected a bunch of footnotes and put them at the end of the document, I'd also wrap them in an <aside> (and then an <ol>, most likely). |
| 16:24 | <mwunsch> | TabAtkins: my thoughts exactly |
| 16:24 | <GPHemsley> | I image Hixie et al. are already aware of this? http://www.zeldman.com/superfriends/guide/ |
| 16:25 | <takkaria> | yup |
| 16:25 | <TabAtkins> | Yeah. |
| 16:25 | <GPHemsley> | s/image/imagine/ |
| 16:25 | <GPHemsley> | k |
| 16:25 | <TabAtkins> | Hit the HTMLWG list yesterday. |
| 16:25 | <GPHemsley> | ah |
| 16:25 | <TabAtkins> | And is already a large thread. |
| 16:25 | <GPHemsley> | perhaps I should start reading that list |
| 16:25 | <TabAtkins> | It's noisier than WHATWG, if you can believe it. |
| 16:25 | <mwunsch> | From the spec: 'For side notes, longer annotations that apply to entire sections of the text rather than just specific words or sentences, the aside element should be used.' |
| 16:26 | <GPHemsley> | s/that list/the HTML5-related lists/ |
| 16:26 | <TabAtkins> | You should definitely be reading at least one. |
| 16:26 | gsnedders | should probably change his W3C account to being an invited expert and use his person address for this month… |
| 16:26 | <gsnedders> | Then change it back to Opera next month… |
| 16:26 | <TabAtkins> | Make sure your mail client groups messages into conversations. ^_^ |
| 16:27 | <GPHemsley> | Yeah, it does. Which list would you recommend? |
| 16:27 | <gsnedders> | But I'm not going to have time to read email this month anyway, so I can't really be bothered :P |
| 16:27 | <AryehGregor> | Speaking of which, should I poke someone to approve my Invited Expert request? It's been about two weeks now. |
| 16:27 | <GPHemsley> | (with link, please) |
| 16:27 | <TabAtkins> | Honestly, both. But be ready to mute conversations that you're not interested in. |
| 16:27 | <TabAtkins> | Aryeh: Yeah, probably. |
| 16:27 | <GPHemsley> | heh |
| 16:27 | <annevk3> | AryehGregor, yes, see WHATWG blog instructions |
| 16:27 | <gsnedders> | AryehGregor: MikeSmith |
| 16:27 | <GPHemsley> | TabAtkins: Oh, I forgot about that feature. :) |
| 16:28 | <MikeSmith> | AryehGregor: I'll check on your application now |
| 16:28 | <TabAtkins> | GPHemsley: I try to read *everything* on the list, but I've muted things coming from other lists that I don't care about, and expect that most people don't want to read as much as me. ^_^ |
| 16:28 | <AryehGregor> | MikeSmith, thanks. |
| 16:28 | <MikeSmith> | (thanks gsnedders for the ping) |
| 16:29 | <GPHemsley> | TabAtkins: Oh, wait... does Gmail have that feature? I thought I remembered seeing it before, but I'm not seeing it now.... |
| 16:29 | <TabAtkins> | Should be in the dropdown? |
| 16:29 | <TabAtkins> | Yeah, under "more actions" |
| 16:29 | <GPHemsley> | I thought |
| 16:30 | <GPHemsley> | TabAtkins: Hmm... only if the message is in the inbox... |
| 16:30 | <GPHemsley> | weird |
| 16:30 | <AryehGregor> | . . . @ superfriends |
| 16:30 | <TabAtkins> | Eh, I guess that makes sense. Why are you muting things that you aren't even currently seeing? |
| 16:31 | <TabAtkins> | I mean, from a principle of "when would be best to expose this option". |
| 16:31 | <TabAtkins> | Since "mute" is basically a perma-archive. |
| 16:31 | <GPHemsley> | TabAtkins: Because I forgot about the feature and don't want to hear any more from conversations that I just keep archiving ;) |
| 16:31 | <GPHemsley> | I personally hate the UI on Gmail's buttons |
| 16:31 | <GPHemsley> | it's not consistent enough |
| 16:32 | <TabAtkins> | Seems consistent in my theme, at least - I use "console". |
| 16:32 | <TabAtkins> | Which reminds me - I've really got to go tweak the display of chatzilla to use a similar theme |
| 16:32 | <TabAtkins> | this black-on-white is murder for my eyes. |
| 16:33 | <GPHemsley> | heh |
| 16:33 | <GPHemsley> | when you switch from the inbox to a label to search results, the archive option moves around |
| 16:33 | <adactio> | Just catching up on the discussion of fuzzy dates with the <time> element... |
| 16:33 | <GPHemsley> | and worse, it's replaced with a remove label button |
| 16:33 | <adactio> | Here's a use case... |
| 16:34 | <TabAtkins> | I have a Consolizer Stylish sheet that I use on most of the web. Makes everything #0d0-on-black FixedSys with italic/bold represented with ASCII instead. |
| 16:34 | <adactio> | Resumés showing work history are usually marked up with months and years, not to the day. |
| 16:34 | <adactio> | This is the kind of information that's already being aggregated (with hResume) by sites like LinkedIn. |
| 16:34 | <GPHemsley> | TabAtkins: Heh. |
| 16:34 | <TabAtkins> | adactio: in my own resume, I simply notate that as the start of the month. |
| 16:35 | <adactio> | I think there's a definite use case for fuzzy dates in work histories for resumés. |
| 16:35 | <adactio> | I'll post it to the list when I get a chance. |
| 16:35 | <TabAtkins> | I haven't yet updated it to use <time>, though - I'm still using <abbr> in hResume. |
| 16:36 | <TabAtkins> | But yeah, post away. Seems valid. |
| 16:36 | <adactio> | TabAtkins: Cheers. |
| 16:36 | <TabAtkins> | So would you be stumping for month-year strings? |
| 16:36 | <Binarytales> | yeah my hresume is full of fuzzy dates |
| 16:36 | <Binarytales> | I have just years in mine aswell |
| 16:37 | <TabAtkins> | Or a more generic notion of fuzzy dates? |
| 16:37 | <gsnedders> | hResume requires exact dates, no? |
| 16:37 | <adactio> | gsnedders: I'm not sure. I'll check. |
| 16:38 | <gsnedders> | experience is hCalendar, and that allows all ISO 8601 |
| 16:38 | <Binarytales> | actually I don't have just years - I have this <abbr class="dtstart" title="2006-01-01">2006</abbr> |
| 16:39 | <Binarytales> | but the intent is just the general idea of 2006 |
| 16:39 | <gsnedders> | Re-reading the spec I think 2006 is fine |
| 16:39 | <gsnedders> | (likewise is 2006001, 2006W011, 20060101…) |
| 16:40 | <adactio> | AFAIK any ISO 8601 date is fine, so that would include "fuzzy" dates like 2009-09 or 2009. |
| 16:40 | <annevk3> | ISO 8601 is not a solution really, it's horribly vague |
| 16:42 | <TabAtkins> | Hmm. RFC 3339 (which microformats refers to with a SHOULD) says that dates must be exact. |
| 16:42 | <gsnedders> | annevk3: I guess hCalendar uses ISO 8601 because iCalendar does |
| 16:43 | <adactio> | annevk3: it's horribly vague for adding a meeting to a calendar. It's perfectly fine for finding gaps in work history. |
| 16:43 | <Binarytales> | gsnedders - the microformats wiki says "The more complex formats like week numbers and ordinal day are not permitted" |
| 16:44 | <Binarytales> | http://microformats.org/wiki/iso-8601 - so 2006001 and 2006W011 wouldn't be valid |
| 16:44 | <gsnedders> | Binarytales: No, that's talking about RFC 3339, which is a subset. |
| 16:44 | <adactio> | So if the <time> element is *just* for adding appointments to calendars, then yeah, there's no point allowing fuzzy dates. But if the spec doesn't proscribe legitimate uses (like resumé aggregation and comparison) then fuzzy dates (i.e. ISO 8601) should be allowed. |
| 16:44 | <gsnedders> | Binarytales: hCalendar goes against the SHOULD and uses ISO 8601 not RFC 3339 |
| 16:45 | gsnedders | thinking compiling code with his laptop on his lap was a bad idea |
| 16:45 | <Binarytales> | oh right. |
| 16:45 | <annevk3> | adactio, I mean the spec |
| 16:45 | <adactio> | annevk3: ah right, sorry. |
| 16:46 | <jgraham> | FWIW the resume use case seems reasonable to me although I don't know how you would map it to useful apis |
| 16:48 | <Binarytales> | The point I was trying to make earlier was that if you give authors <time> they are going to want to wrap _all_ their dates and time with it. Under the current behaviour it won't be long before the web is full of nonconforming pages |
| 16:49 | <GPHemsley> | TabAtkins: OK, I'm officially subscribed to the spec and implementors mailing lists. Don't make me regret it. ;) |
| 16:50 | <TabAtkins> | I will spam the list just for you, GPHemsley. |
| 16:50 | <GPHemsley> | <3 |
| 16:52 | <Binarytales> | I live near a place called Helmsley, it's pretty |
| 16:52 | <GPHemsley> | meh |
| 16:52 | <GPHemsley> | that word is the bane of my existence |
| 16:53 | <AryehGregor> | MikeSmith, thanks. |
| 16:54 | <MikeSmith> | AryehGregor: np. sorry about the delay |
| 17:23 | <cryzed> | Hey :), I'm using html5lib for Python, a fairly old version tho. |
| 17:24 | <cryzed> | I was wondering if html5lib.parse still worked in the newest version |
| 17:24 | <gsnedders> | It does, just differently :P |
| 17:25 | <gsnedders> | (It puts everything into the HTML namespace now) |
| 17:25 | <cryzed> | So as a user of |
| 17:25 | <cryzed> | html5lib.parse(some_kind_of_stringio, 'beautifulsoup') |
| 17:25 | <cryzed> | I shouldn't "feel" a difference, right? |
| 17:26 | <gsnedders> | Oh, I think it's now rather broken with BS |
| 17:26 | <cryzed> | I just tested it |
| 17:26 | <cryzed> | seems to work |
| 17:26 | <gsnedders> | (But I could be wrong) |
| 17:26 | <gsnedders> | Then I guess it should work |
| 17:26 | <jgraham> | It just ignores ns stuff with bs for the moment |
| 17:26 | <cryzed> | Because last time I checked it kep throwing errors |
| 17:26 | <cryzed> | "ns stuff"? |
| 17:26 | <cryzed> | Non-sense? |
| 17:26 | <TabAtkins> | namespace |
| 17:26 | <jgraham> | Yeah I wallpapered over the underlying issue |
| 17:27 | <jgraham> | By making it just throw warnings if you try to do something that will put elements in a non-html namespace |
| 17:27 | <cryzed> | Does that affect the way I work with it or is it "just" something internal? |
| 17:27 | <jgraham> | cryzed: As long as you only ever parse documents that don't contain a <svg> or <mathml> tag it should work fine |
| 17:28 | <gsnedders> | cryzed: It means you can't use a document like <html><title>foo</title><svg><desc>foo</desc></svg>… |
| 17:28 | <cryzed> | So self-invented tags are a no-no |
| 17:28 | <cryzed> | or is svg html5? |
| 17:28 | <gsnedders> | It's not self-invented |
| 17:28 | <gsnedders> | SVG can occur in HTML documents in HTML 5. |
| 17:28 | <jgraham> | It is svg and mathml in html5 |
| 17:28 | <cryzed> | Oh - so it basically needs updating, right? |
| 17:28 | <gsnedders> | And SVG elements are in the SVG namespace |
| 17:29 | <cryzed> | "basically", I don't want to force you or anything |
| 17:29 | <gsnedders> | BeautifulSoup has no concept of XML namespaces |
| 17:29 | <cryzed> | BeautifulStoneSoup? *is probably talking about something different* |
| 17:30 | <gsnedders> | Doesn't support XML namespaces, as far as I know |
| 17:31 | <cryzed> | "[...] Beautiful Soup is a Python HTML/XML parser designed for quick turnaround projects like screen-scraping. [...]" |
| 17:31 | <gsnedders> | XML namespaces is not part of the XML spec |
| 17:31 | <jgraham> | cryzed: As far as I can tell it has no namespace support |
| 17:31 | <gsnedders> | Namespaces for XML is a different spec, which almost everything that uses XML relies upon. |
| 17:32 | <gsnedders> | As far as I can tell BeautifulSoup does not support XML namespaces. |
| 17:32 | <cryzed> | Okay - I honestly don't really understand how those namespaces work, or how they are used internally - but I guess I'll just believe you |
| 17:32 | <cryzed> | but that's really too bad |
| 17:32 | <cryzed> | I really like BeautifulSoup - it's sad that it's dying more or less |
| 17:33 | <TabAtkins> | Augh god, where the hell are these chrome:// urls pointing?!? I want to alter an existing file, but don't know where to find it. >_< |
| 17:33 | <gsnedders> | TabAtkins: Into chrome :P |
| 17:34 | <TabAtkins> | Incorrect, gsnedders. This is Firefox. ^_^ |
| 17:34 | <gsnedders> | Into the chrome :P |
| 17:34 | <TabAtkins> | Also lies, gsnedders. There are no CSS files hidden in the chrome. |
| 17:35 | <jgraham> | TabAtkins: For example? |
| 17:35 | <TabAtkins> | Trying to alter the chatzilla css, located at chrome://chatzilla/skin/output-default.css |
| 17:37 | <TabAtkins> | I'm afraid it's going to end up in a .jar, so the system sarch won't find it. |
| 17:39 | <TabAtkins> | Indeed. This file, it does not exist as a bare file anywhere on my c: drive |
| 17:42 | <TabAtkins> | Of course, I can also just type the chrome url into the browser bar, then copypasta into a new file. |
| 17:47 | <jgraham> | TabAtkins: It will be somewhere in chatzilla.jar/skin or something |
| 17:47 | <jgraham> | I guess |
| 17:48 | <TabAtkins> | Yeah, dun worry. I'm working around it. |
| 17:48 | jgraham | hasn't touched mozilla jar files for a long time |
| 17:48 | <jgraham> | (and I have never used chatzilla) |
| 17:49 | <TabAtkins> | I got the source of the two css files, and cz allows you to change what CSS file it points to, so I'm good. |
| 18:26 | <takkaria> | Philip`: you want to add some of the fonts from http://www.1stwebdesigner.com/resources/52-really-high-quality-free-fonts-for-modern-and-cool-design/ to your subsetter |
| 18:26 | <takkaria> | honest :) |
| 18:39 | <Philip`> | takkaria: No I don't, since (I think) very few have acceptable licenses |
| 18:39 | <Philip`> | e.g. the very first one says "This font is freeware for personal and commercial use. ... Editing is only allowed for personal use, dont distribute an edited version of this font!" |
| 18:40 | <Philip`> | (and subsetting involves modifying and distributing) |
| 18:40 | <tantekc> | othermaciej, tabatkins - your feedback on CSS3UI totally makes sense. |
| 18:40 | <TabAtkins> | Argelalhaf;sdjfk I hate people who think they're being nice by letting people share but then lock down remixing. |
| 18:41 | <takkaria> | Philip`: ah, shame |
| 18:41 | <tantekc> | and Boris too - if he's here. |
| 18:42 | <othermaciej> | tantekc: he sometimes is, but not at the moment |
| 18:42 | <TabAtkins> | tantekc: Dont' get me wrong; the ability to style page elements like native UI controls is really useful too, but like maciej said, it's sorta complementary to the issue at hand. |
| 18:42 | <tantekc> | "starting point" is a good way of looking at it |
| 18:42 | <tantekc> | TabAtkins, in many ways, CSS3UI provides the presentational equivalent of what ARIA role does semantically |
| 18:43 | <Philip`> | takkaria: (I haven't checked all the fonts on that list - originally I mostly just looked for ones that were listed as GPL/OFL/etc, and then threw away ones that were particularly stupid fonts, because starting from lists of good free fonts would result in very few with acceptable licenses) |
| 18:43 | <TabAtkins> | The "issue at hand" being the exact opposite - styling native UI controls like page elements. |
| 18:43 | <TabAtkins> | tantekc: Yeah, that's a good way to put it. |
| 18:43 | <tantekc> | and thus is still quite useful |
| 18:43 | <tantekc> | since people do build buttons out of divs etc. |
| 18:43 | <TabAtkins> | Yup. |
| 18:44 | <TabAtkins> | Just last week I styled a <label> as a button - luckily I *generally* have a non-native look for the buttons in my intranet apps. |
| 18:44 | <TabAtkins> | (It was a bit of a hack - the <label> activated an invisible <input>, triggering a jQuery datepicker.) |
| 18:45 | <TabAtkins> | I use the non-native look precisely so I can be flexible like that, because I can't style things like the native buttons. |
| 18:45 | <tantekc> | TabAtkins - you should be able to though. And that's partly why CSS3UI focused on what it did. |
| 18:46 | <TabAtkins> | Nod, I just meant that I can't do so *currently*. I'd like to be able to. ^_^ |
| 18:46 | <takkaria> | hmm, the discusison on public-htmlhas been pretty technical and not spammy for a few days now |
| 18:46 | <tantekc> | by providing a CSS way of doing *default* form element presentation, browser implementers could rely less on custom code specifically for form elements |
| 18:46 | takkaria | is impressed |
| 18:47 | <TabAtkins> | takkaria, it's because we're discussing actual work, rather than process. Discussion rather than meta-discussion. ^_^ |
| 18:48 | <takkaria> | I really haven't seen public-html be so useful for a long time |
| 18:48 | <takkaria> | though there were a few weeks when it was fairly decent back in early 2008 IIRC |
| 18:49 | <TabAtkins> | I blame the Superfriends for this burst of productivity. Also Maciej. |
| 18:53 | <othermaciej> | tantekc: my experience is that content authors use <divs> solely so they can get a custom-looking button in a cross-browser way, and are not very interested in making <divs> look exactly like native buttons - we only really use 'appearance' as part of our internal implementation of form control rendering |
| 18:53 | <tantekc> | othermaciej - right, that was part of my thinking as well |
| 18:54 | <tantekc> | that the more that implementations were built to handle CSS3UI - the more they would also allow "normal" styling of form elements |
| 18:54 | <tantekc> | CSS3UI provided the necessary implementation abstraction |
| 18:54 | <TabAtkins> | othermaciej: Really? I'd be quite interested in making things look like native controls, but I don't care enough about it to use a solution that won't work in IE. |
| 18:55 | <tantekc> | basically, form element appearance should be fully defined by CSS, not by HTML |
| 18:55 | <tantekc> | doing so enables the proper cascade of platform / user agent / author styles |
| 18:55 | <tantekc> | for both form elements and normal elements |
| 18:55 | <tantekc> | being styled either like "normal" elements, or like form elements |
| 18:57 | <othermaciej> | we ended up allowing a lot of styling without setting appearance to normal, to go along with what other browsers do |
| 18:57 | <othermaciej> | but I'm not sure if there is a wide interoperable range of what form control styling you can do cross-browser |
| 18:59 | <TabAtkins> | Amusing: a high-school friend and an internet friend got into a row on one of my facebook posts. Now the two of them have posts making fun of each other showing up as consecutive updates for me. ^^; |
| 19:05 | <jlebar> | uuid |
| 19:05 | <jlebar> | whoops...wrong window. |
| 19:05 | <TabAtkins> | uuids are never wrong. |
| 19:33 | <annevk3> | Philip`, encoding stats ping |
| 19:33 | <annevk3> | :) |
| 19:52 | <deadowl> | Could HTML5 have a dummy tag to signify that in a specific case when extracting from a range, a parent element's children got cut out of the extraction? |
| 19:53 | <hober> | deadowl: I'm afraid I don't follow. |
| 19:53 | <deadowl> | hard to explain |
| 19:54 | <deadowl> | So let's say a user selects a section of an unordered list, but not the entire thing. |
| 19:54 | <deadowl> | You can get the selection object which will provide you with a valid unordered list, but no way to signify it's not the entire unordered list. |
| 19:56 | <deadowl> | Do you follow yet? |
| 19:57 | <deadowl> | the parts that got cut off from the document selection could be at the beginning or end. So it would be nice to be able to represent that somehow. |
| 19:58 | <deadowl> | and it could extend to several elements within that selection. |
| 19:58 | <deadowl> | Mostly I'm trying to do templating with ranges, but that's the simplest example I can think of. |
| 20:00 | karlushi | wonders if there was any attempts in the past to have javascript control over an animated gif in browsers. |
| 20:00 | <karlushi> | stop, next frame, previous frame, etc. |
| 20:12 | <deadowl> | karlushi: don't think so |
| 20:15 | <TabAtkins> | Though, given current processing, you could probably fake it with lots of gifs and a setInterval() |
| 21:29 | <annevk2> | adactio, not sure if your routine includes reading these logs, but http://dev.w3.org/html5/html4-differences/ dropped the space too now |
| 21:39 | <cardona507> | can anyone point me to a link that shows what browsers support what codec for <video>? |
| 21:41 | <jcranmer> | Mozilla-based, Opera = theora; Safari = h.264; chromium = both; IE = neither |
| 21:41 | <jcranmer> | well, Chrome; I don't know about chromium |
| 21:42 | <Philip`> | More accurately, Safari = whatever QuickTime supports (which by default includes H.264 and not Theora), or something like that |
| 21:43 | <AryehGregor> | Chromium doesn't support H.264, only Theora. |
| 21:43 | <Binarytales> | I don't think Chromium support H.264 due to license issues |
| 21:43 | <AryehGregor> | I assume you can compile it to support whatever you want, though. |
| 21:43 | <gsnedders> | Chrome supports both, though |
| 21:44 | <cardona507> | what is in the spec- h.264? |
| 21:44 | <jcranmer> | nothing |
| 21:44 | <cardona507> | how about <audio>? |
| 21:44 | <jcranmer> | it used to be theora, way back when |
| 21:45 | <jcranmer> | now it's nothing until the Great Codec War finishes |
| 21:51 | <gsnedders> | It was clear soon after that got into the spec that would have to go |
| 21:52 | <Lachy> | why do people make wild claims about what elements are not meant for, when in fact, that's what they were designed for?! http://html-five.net/2009/07/20/aside-is-not-a-sidebar/ |
| 21:52 | <Lachy> | (admittedly, the spec's definition of aside isn't very clear) |
| 21:55 | <cardona507> | what is the browser support for <audio>? |
| 21:55 | <Lachy> | cardona507, Firefox and Safari support it |
| 21:55 | <cardona507> | vorbis and mp3? |
| 21:56 | <Lachy> | Firefox supports Ogg Vorbis, Safari supports anything that QuickTime will play |
| 21:56 | <cardona507> | hmmm- thanks |
| 21:59 | <Philip`> | Does Firefox support WAV? |
| 22:00 | <TabAtkins> | Philip`, yes. |
| 22:00 | <gsnedders> | Cat People (Putting Out Fire) by David Bowie is awesome. |
| 22:02 | <TabAtkins> | Lachy: if <aside> is meant for an actual *website* sidebar, that's *way* not clear from the spec. Magazine sidebar, yes. |
| 22:02 | <TabAtkins> | But a website sidebar is just "stuff that lives on the side of my section", to complement header and footer as "stuff the lives at the top/bottom of my section". |
| 22:05 | <TabAtkins> | Lachy: It also feels totally weird to have a single element be both a sidebar and an aside. The stuff that <aside> is meant for per spec *might* be on the side, and commonly are by typographic convention, but they could be right in the middle of content too, just typographically offset from the surrounding content with borders and font to indicate that they're not really part of the content flow. |
| 22:06 | <TabAtkins> | It's like <footer> - it's currently trying to pull double-duty as a structural element ("stuff that goes at the bottom of the section") and a semantic element ("metainfo about the article"). |
| 22:06 | <TabAtkins> | There will be friction and confusion *constantly* about this. |
| 22:08 | <cardona507> | what is the solution? |
| 22:10 | <TabAtkins> | The solution, imo, is to split the structural from the semantic. For footer, make <footer> an exact counterpart to <header> as merely a grouper, and then take the current <footer> semantics and stuff them into a new element without a misleadingly structural name. Do the same with <aside> - split it into structural and semantic elements |
| 22:14 | <AryehGregor> | Or just ax them all. |
| 22:14 | <Binarytales> | whenever I try and think about this i get confused about article and section and my head starts hurting |
| 22:15 | <TabAtkins> | Use <section> if the element could reasonably have a heading applied to it. |
| 22:15 | <TabAtkins> | Use <article> if the element could be fullscreened and still be useful. |
| 22:15 | <TabAtkins> | That's about it. |
| 22:20 | <Binarytales> | can both articles and sections have headers and footers? |
| 22:21 | <gsnedders> | yeah |
| 22:22 | <TabAtkins> | An <article> is just a <section> that would make sense all by its lonesome. |
| 22:30 | <Binarytales> | When you really study it this stuff makes sense but it sure isn't obvious |
| 22:31 | gsnedders | wonders how ever much he's going to end up spending on music this month |
| 22:32 | <TabAtkins> | Binarytales: I think the spec just needs to have some plain language like that. It's super easy when you have a good sniff-test. The problems come only when you're trying to base things purely off of a vague semantic description. |
| 22:35 | <Binarytales> | Some of the new elements are just really badly named, authors are going to want to instinctively use them for stuff that they weren't intended for. It's hard though 'cos once you work out the intent of the spec the names kind make sense |
| 22:39 | <Binarytales> | maybe <footer> should be called <meta> |
| 22:39 | <hober> | we already have one of those |
| 22:41 | <cardona507> | hixie - is there still room in the list of 20 for TPAC in november?? |
| 22:41 | <Hixie> | yep |
| 22:41 | <Hixie> | you're a member now? |
| 22:41 | <Hixie> | i'll reply to your last e-mail |
| 22:41 | <cardona507> | thanks |
| 22:41 | <Hixie> | np |
| 22:42 | <Binarytales> | Well it seems to me that the intent for <footer> is for the same sort of information that <meta> in the <head> allows - it's just visible data and not hidden data |
| 22:43 | <hober> | <meta> is an empty element, and that probably can't be changed. also, <meta> basically means "here's some hidden metadata", both in its <head> usage and it's Microdata usage. |
| 22:44 | <TabAtkins> | BinaryTales: Yeah, <meta> is already empty. Also, normal people don't know what <meta> means. |
| 22:44 | <hober> | the intent for <footer> is to contain foot-matter in sectioning elements, hence the desire to change its content model |
| 22:44 | <TabAtkins> | I suggest <info> |
| 22:44 | <hober> | (instead of renaming it to match its content model) |
| 22:44 | <Binarytales> | yeah info works |
| 22:44 | <TabAtkins> | hober: I'm for doing both. Changing its content model, and then renaming the current content model. |
| 22:44 | <Binarytales> | hober - surely the content model is more important |
| 22:45 | <hober> | I don't think <footer>'s current content model has a compelling use-case, honestly. |
| 22:46 | <hober> | like <address>, <footer>-as-currently-defined will likely almost never be used correctly, given the prevalence of "fat footers" |
| 22:46 | <Lachy> | TabAtkins, aside was designed to be a sidebar. The extra uses that are currently illustrated in the spec were added on later, apparently to the detriment of it's initial use case |
| 22:47 | <TabAtkins> | Lachy: Then they need to be removed. If it's meant to be structural, let it be structural. If it's meant to be semantic, let it be semantic. |
| 22:48 | <Lachy> | TabAtkins, I personally don't agree with the extra uses that Hixie made up for it. I don't think they were based on any observations of real world content I'm aware of |
| 22:48 | <Binarytales> | i think aside makes more sense now. in most use cases a sidebar is either unrelated or nav or in fact <footer> stuff that happens to be places at the side |
| 22:48 | <TabAtkins> | Lachy: pull-quotes with <aside>, yes or no? |
| 22:49 | <Lachy> | undecided. |
| 22:49 | <hober> | Personally I'd like it if <header> were restricted (insofar as author conformance is concerned) to be the first child of its sectioning element (ignoring whitespace text nodes), and analagously <footer> as the last child |
| 22:49 | <Lachy> | IIRC, authors use <blockquote> for pull quotes |
| 22:49 | <Lachy> | and some use things like <div class="pullquote"> |
| 22:50 | <Lachy> | not really sure what's best for it. It's not something I ever do myself |
| 22:50 | <TabAtkins> | Indeed. Problem, though, is that pullquotes are often *not* meant to be read as part of the content. They're either repeating a quote already present in the article, just to highlight it, or sometimes pulling in quotes from completely different sources that are related-but-tangential. Commentary, in other words, not content. |
| 22:51 | <Lachy> | though I'd probably lean towards that not being an ideal use of aside |
| 22:51 | <TabAtkins> | Using just <blockquote> or <div> means that it's supposed to be part of the content. |
| 22:51 | <Lachy> | hmm, maybe. |
| 22:51 | <TabAtkins> | We had some nice examples yesterday from the BBC website. |
| 22:51 | <Binarytales> | the poignant guide is a good example of lots of various asides |
| 22:52 | <Lachy> | Binarytales, link? |
| 22:53 | <Binarytales> | it might be down... it was one of _why's creation... i'll check |
| 22:53 | <Lachy> | Binarytales, is that the one about Ruby? |
| 22:53 | <Binarytales> | yeah |
| 22:54 | <TabAtkins> | Basically, the current spec text is *completely* about related-but-tangential content within an article, *not* sidebars. If it ever suggested that it was to be used for sidebars, that implication is long gone now. |
| 22:54 | <Lachy> | ok, I'm aware of it, though I haven't read it and can't recall any examples of asides from it |
| 22:54 | <Lachy> | TabAtkins, I know. That's a major problem with the spec |
| 22:55 | <TabAtkins> | But we like it how it is. ^_^ |
| 22:55 | <Lachy> | I don't know what happened to the stuff about sidebars. I'm sure it used to be in there, and it should still e |
| 22:55 | <Lachy> | *be |
| 22:55 | <TabAtkins> | Can you check commits on a particular section? |
| 22:55 | <Lachy> | I think that's difficult |
| 22:56 | <TabAtkins> | I think so too. |
| 22:56 | <Lachy> | though if you know how to use SVN, feel free to try |
| 22:56 | <TabAtkins> | You'd probably want to jump through the diffs until you ran into a change. |
| 22:56 | <TabAtkins> | Yeah, I may try after work. |
| 22:56 | <Binarytales> | Okay here is another example http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html |
| 22:56 | <Binarytales> | about two thirds of the way down there is an explanation of when Dionysuis think Christ was born |
| 22:57 | <Binarytales> | that would be marked up as an <aside> |
| 22:57 | <Lachy> | Binarytales, hmm, yeah, I guess |
| 22:58 | <TabAtkins> | Yup. That's the use of <aside> that I'm angling for, that's currently spec-supported. |
| 22:58 | <Lachy> | well, we still need sidebars restored in some way |
| 22:58 | <Lachy> | or just be stuck with <section> |
| 23:00 | <TabAtkins> | The only thing wrong with <section> is that sidebars *are* so common that it probably falls under the same justification as header/footer |
| 23:00 | <Lachy> | it kind of sucks to overload the element with two distinct purposes, and it would also suck to have to introduce two separate elements to address each case |
| 23:00 | <TabAtkins> | Plus, it would invalidate Hixie's rule of main content being "anything that's not header/footer/aside/nav" |
| 23:00 | <Hixie> | what _are_ y'all talking about |
| 23:01 | <Binarytales> | Lachy - can you show a use case where us would need a <sidebar> that isn't already served by a current element? |
| 23:01 | <Lachy> | Hixie, <aside> |
| 23:01 | <Lachy> | Hixie, the fact that it can be used for tangentially related content, and for page sidebars |
| 23:02 | <Lachy> | Binarytales, it avoids the need to have to use id="sidebar" or class="sidebar" (or equivalent) |
| 23:02 | <Hixie> | "tangentially related content" is semantic-speak for "sidebar" |
| 23:03 | <TabAtkins> | BinaryTales: nod to Lachy. It falls under the same justification as <header> and <footer> - they're *so* common that they can be justified. |
| 23:03 | <TabAtkins> | Hixie: I disagree. ^_^ Plus so do lots of other people, apparently. |
| 23:03 | <TabAtkins> | pullquote is tangentially related content. A digression is tangentially related content. A blogroll is *not*. It's just a sidebar. |
| 23:04 | <Lachy> | Hixie, as we're discussing, there are two different types of tangentially related content. There's the page side bar, much like you find in, say, the left colum of wikipedia, and there's the kind that Binarytales pointed out in the quirksmode article |
| 23:05 | <Hixie> | a blogroll is tangentially related content |
| 23:05 | <Hixie> | Lachy: one is tangentially related to an <article>, and the other to the <body> |
| 23:06 | <Lachy> | Hixie, either way, the spec needs to be fixed to a) make it clear that such sidebars are a form of tangentially related content, or b) find an alternative solution |
| 23:06 | <Hixie> | in what world could a blog's blogroll not be considered related to the blog? |
| 23:07 | <TabAtkins> | In the world where you'll still have to use a class to differentiate the two for styling? |
| 23:07 | <TabAtkins> | All my "tangent" asides can probably be styled the same, while my sidebar will be completely different. |
| 23:08 | <Hixie> | sure |
| 23:08 | <Hixie> | article > aside vs body > aside |
| 23:10 | <Hixie> | in the HTML5 spec, there are many classes of <aside>s -- .example, .note, .warning, .XXX, the issue markers on the side, the inline issue markers that jgraham inserts, etc |
| 23:10 | <Hixie> | they all have different styles |
| 23:10 | <TabAtkins> | Yeah, all those are fine asides. |
| 23:10 | <TabAtkins> | If you do want sidebars to be <aside>, then you've *got* to edit the spec. The current examples give a *completely* different impression of the purpose of the element. |
| 23:12 | <Lachy> | Hixie, it seems like authors are trying to find and expect to see a clear distinction between elements used for overall page structure, and elements used for smaller sub-sections |
| 23:12 | <TabAtkins> | Lachy's got it. |
| 23:12 | <Lachy> | so the spec needs to address that issue in some way. |
| 23:12 | <Hixie> | if you want more examples, or different examples, file a bug |
| 23:12 | <Binarytales> | i think its a context problem with the whole spec itself. nearly all the examples are from the context of a particular set of data. and blog post, an article, etc. There is a lack of example and clarity for the context of the greater context, the whole webpage itself |
| 23:13 | <TabAtkins> | There's already 20 or so emails on the subject. ^_^ |
| 23:13 | <Lachy> | I'm not sure if examples would address the entire issue, though it would help |
| 23:13 | <Hixie> | if there's e-mails, that works too :-) |
| 23:13 | <TabAtkins> | The Superfriends got a lot of discussion moving. |
| 23:14 | <Lachy> | Hixie, I will think about it and get back to you with, hopefully, a concrete way to address the issue |
| 23:15 | <Lachy> | TabAtkins, yeah, the "Superfriends" had some very good, constructive feedback, although some bits are a little misguided |
| 23:15 | <Binarytales> | this is fascinating stuff but alas The Wire is on.... |
| 23:15 | Hixie | hasn't seen any mail about their feedback |
| 23:15 | <Hixie> | did they send that in? |
| 23:15 | <Lachy> | but I find it somewhat disturbing that they called themselves the "superfriends" |
| 23:15 | <Hixie> | or did my spam filters catch it again |
| 23:15 | <TabAtkins> | Hixie: It's been linked. |
| 23:15 | <Lachy> | Shelley sent it |
| 23:15 | <Binarytales> | http://www.zeldman.com/superfriends/guide/ |
| 23:16 | <TabAtkins> | "HTML5 feedback from prominent designers" and "Implementor feedback on new elements in HTML5" |
| 23:16 | <TabAtkins> | both started yesterday. |
| 23:16 | <Hixie> | HTML5 feedback from prominent designers was apple's feedback, no? |
| 23:16 | <TabAtkins> | Though the latter was actually started by Maciej. |
| 23:16 | <Hixie> | er wait |
| 23:17 | <Hixie> | the other one was i mean |
| 23:17 | <Lachy> | Hixie, http://lists.w3.org/Archives/Public/public-html/2009Aug/1473.html |
| 23:17 | <TabAtkins> | Yeah, but the superfriends stuff got included into the whole discussion. |
| 23:18 | <Hixie> | oh, i see, there was no actual feedback in those e-mails except for lachy's e-mail |
| 23:18 | <Hixie> | that's why it didn't get logged |
| 23:19 | <Lachy> | Hixie, don't you count e-mails that link to actual feedback, like Shelley's did? Or do you log those pages elsewhere? |
| 23:20 | <Hixie> | i didn't save that one because i'm expecting them to actually send the feedback |
| 23:20 | <Hixie> | and it's far easier for me to deal with e-mails with feedback than with e-mails with links to feedback |
| 23:20 | <Hixie> | since otherwise i have to dig up their e-mail addresses, etc |
| 23:20 | <Lachy> | ah, ok |
| 23:21 | <Lachy> | I didn't think they would repeat themselves in an e-mail, especially now that the link has already been sent |
| 23:22 | <Hixie> | they said they would |
| 23:23 | <Hixie> | so... |
| 23:27 | <othermaciej> | I think they are planning to post some feedback in email |
| 23:27 | <othermaciej> | but it seems worth reading in any case |
| 23:30 | <TabAtkins> | I think it would be worthwhile to explicitly talk about the distinction between page-structure and section-content, and then state that some elements (like <aside>) fill both roles. |
| 23:31 | <TabAtkins> | Just a quick mention would work; a sentence or so stating that explicitly in <aside>, and again perhaps in <footer> (though the semantics of footer are still utterly inappropriate for the intended structural role, unlike <aside>). |
| 23:33 | <TabAtkins> | I'll write up some example text and email it tonight. |
| 23:47 | <TabAtkins> | Okay, question: Say I have a sidebar composed of a site-nav, a blogroll, and a favorite quote. The first is obviously a <nav>, the latter two are <aside>s. However, I need to wrap the whole thing in a container to get it to sit on the side properly. This container should be a <div>, right? |
| 23:47 | <hober> | no, I think the sidebar itself is the <aside>, and it contains a <nav> and some other stuff |
| 23:48 | <Hixie> | <aside> <nav> </nav> <section> </section> <blockquote> </blockquote> </aside> |
| 23:48 | <hober> | the blogroll is a <ul> I imagine |
| 23:49 | <TabAtkins> | All right. If I *didn't* need to wrap them together (or explicitly need to *not* wrap them together), would the latter two be <aside>s by themselves? |
| 23:50 | <hober> | that would be one way to do it, sure. |
| 23:50 | <TabAtkins> | And is the meaning of <nav> changed by being wrapped in an <aside>? |
| 23:50 | <TabAtkins> | As opposed to putting a <nav> in a <header> or <footer>, that is. |
| 23:51 | <hober> | AFAICT the meaning of <nav> wouldn't change, no |
| 23:52 | <hober> | Nothing in #the-nav-element suggests that the semantics of <nav> change based on parentage |
| 23:52 | <TabAtkins> | I'm just making sure that it's acceptable to have a bare <nav> acting as a sidebar without <aside>. |
| 23:52 | <hober> | if the only thing your sidebar contains is navigation, then that sounds like a fine use of <nav> |
| 23:54 | <TabAtkins> | Kk. I've got no particular problem with this, it's just that when an element is stated as "being for sidebars", I need to make sure that it's not *required* for sidebars. |
| 23:54 | <Hixie> | i think your problem here is that you are trying to design your markup around your presentation |
| 23:54 | <TabAtkins> | Hixie: I'm actually trying to discover to what extent I can *not* do that. |
| 23:54 | <Hixie> | you should write your markup with no CSS at all, and then only once you're completely happy with the markup without styles, open your css file in a text editor :-) |
| 23:54 | <TabAtkins> | So then I can suggest spec edits to make it clear to others. |
| 23:55 | <TabAtkins> | That's precisely what I already do. ^_^ |
| 23:55 | <Hixie> | good :-) |
| 23:56 | <TabAtkins> | Dude, you and tantek were my gods when I started webcoding. You guys were the first blogs I stumbled across that made sense. |
| 23:57 | <TabAtkins> | So, would it be *acceptable* to have <div><nav /><aside .blogroll /><aside><blockquote /></aside></div>? Just trying to ascertain the flexibility that is intended here. |
| 23:58 | <hober> | now that pubdate="" is on <time>, I think it would make more sense if it applied to the nearest ancestor <article> element, or <body> if there is no such ancestor |
| 23:59 | <TabAtkins> | It already applies to the nearest ancestor <article>. Applying it to <body> is definitely needed, though, as <body> implies the semantics of <article>. |
| 23:59 | <hober> | I'm imagining a page that is just a document, where <body> is the sectioning element that represents the entire document. there's no need to add an <article> descendent that contains all descendents of <body>... |
| 23:59 | <TabAtkins> | hober: yeah |