| 09:02 | <Hixie> | maybe the solution to <switch> is simply to have a "hidden" attribute |
| 09:02 | <Hixie> | and some API to toggle one element off and another one on |
| 09:03 | <Hixie> | or just require people to do loginform.hidden = true; game.hidden = false; |
| 09:03 | <Hixie> | certainly would be simple |
| 09:05 | <krijnh> | Hixie: A global hidden attribute? |
| 09:05 | <Hixie> | yeah |
| 09:05 | <hsivonen> | Hixie: would it in terms of CSS toggle display: none; instead of visibility: hidden;? |
| 09:05 | <Hixie> | i'm just trying to work out the semantic part, i haven't really thought about the rendering |
| 09:06 | <Hixie> | i guess from a rendering perspective you'd have [hidden] { display: none; } |
| 09:06 | <krijnh> | <foo hidden="false"> |
| 09:06 | <hsivonen> | I wonder if the name confuses authors who know about CSS "hidden" |
| 09:07 | <krijnh> | Prototype JS uses hidden() as well |
| 09:07 | <krijnh> | foo.hidden() => boolean |
| 09:07 | <aroben> | Hixie: might be easier to understand .visible instead of .hidden, since it's positive |
| 09:08 | <Hixie> | we need something that defaults to visible |
| 09:08 | <krijnh> | With .visible I'd think about visibility: hidden|visible |
| 09:08 | <Hixie> | so the attribute, if it's an attribute, has to hide it |
| 09:08 | <hsivonen> | invisible |
| 09:08 | <krijnh> | I still don't get why that should be in HTML.. |
| 09:08 | <Hixie> | invisible could work, though i'd like a name that more obviously means the content is irrelevant... maybe irrelevant="" |
| 09:09 | <Hixie> | krijnh: imagine you're doing a web based game |
| 09:09 | <Hixie> | krijnh: and you have a login page, then a game page, then a game over page with the high score |
| 09:09 | <Hixie> | krijnh: and these are all just <section>s in a single HTML page |
| 09:09 | <Hixie> | krijnh: the game page is semantically irrelevant until the login page has been used to log in |
| 09:10 | <Hixie> | krijnh: and then the login page is semantically irrelevant once the game has started |
| 09:10 | <krijnh> | Yeah, I get that part |
| 09:10 | <Hixie> | krijnh: even without CSS, you'd still want those parts of the page to not be shown |
| 09:10 | <Hixie> | krijnh: that is, their presence is not stylistic |
| 09:10 | <Hixie> | krijnh: it's semantic |
| 09:11 | <krijnh> | For backwards compatibility it should be three separate pages anyway, |
| 09:11 | <Hixie> | well for now, sure, but eventually once html5 has a large install base, that won't be a problem |
| 09:12 | <Hixie> | and in the meantime you can use it if you put something in your stylesheet or script |
| 09:12 | <krijnh> | So you could have a website in one big file, and swap hidden sections while you navigate through it |
| 09:13 | <krijnh> | Or is it only for a page where you have to 'start' at one section |
| 09:14 | <Hixie> | krijnh: it's for things where it would make no sense to show everything at once |
| 09:15 | <Hixie> | krijnh: where the other thing would actually be completely irrelevant, unusable, and nonsensical if shown |
| 09:15 | <Hixie> | krijnh: if it would make sense to have the two things opened in two tabs or two windows at once, then this feature wouldn't apply |
| 09:16 | <Hixie> | e.g. it wouldn't be appropriate to use this for tabs, or to split a big page into multiple panels, etc |
| 09:16 | <krijnh> | So what happens when you make multiple sections visible at once? |
| 09:17 | <krijnh> | If it's really a switch thing, only one can be 'visible', right? |
| 09:17 | <Hixie> | how do you mean? |
| 09:17 | <krijnh> | Well, say you have 3 sections, for that game |
| 09:17 | <krijnh> | Only one is relevant |
| 09:18 | <krijnh> | Now you switch to a different section |
| 09:18 | <krijnh> | foo1.hidden = true; foo2.hidden = false |
| 09:18 | <krijnh> | Or something |
| 09:18 | <krijnh> | What if you don't hide foo1 |
| 09:18 | <krijnh> | Then it's no switch |
| 09:19 | <peepo> | Is there an accessibility bod contributing to this thread? |
| 09:19 | <krijnh> | So those two statements should be just one, relevantRightNow = foo2 |
| 09:19 | <Hixie> | krijnh: well, you could imagine cases where something might become relevant but otherwise might not be, independent of other things, e.g. a notification "window" |
| 09:19 | <krijnh> | Hixie: If you could make all sections visible at once, I don't get why they couldn't be separate pages |
| 09:20 | <peepo> | http://ua-games.gr/game-over |
| 09:20 | <peepo> | We have just released "Game Over!", the world's first universally |
| 09:20 | <peepo> | inaccessible game! |
| 09:20 | <peepo> | Game Over! aims to provide game developers with a first-hand |
| 09:21 | <peepo> | (frustrating) experience of how it feels interacting with a game that |
| 09:21 | <peepo> | is not accessible due to the fact that important accessibility design |
| 09:21 | <peepo> | rules were not considered or applied. |
| 09:21 | <Hixie> | krijnh: imagine your page is a status dashboard for some network service, and there are three servers, and each one can sent a status message at any time |
| 09:21 | <peepo> | have to run..later |
| 09:21 | <Hixie> | krijnh: the status window for a server is irrelevant/nonsensical/unusable unless the server is sending a message |
| 09:22 | <Hixie> | krijnh: but all three servers might send a message at once, in which case all three windows are relevant/usable |
| 09:22 | <Hixie> | krijnh: but the messages aren't "pages" as far as the user is concerned |
| 09:22 | <Hixie> | (though i guess they might well be "pages" in the REST sense) |
| 09:23 | <krijnh> | Hmm |
| 09:34 | <krijnh> | Hixie: Sorry, I was thinking about a <switch><case>..</case><case>..</case></switch> kinda thing :) |
| 09:34 | <Hixie> | yeah that was my original thought too |
| 09:34 | <Hixie> | i think an attribute is more flexible |
| 09:35 | <Hixie> | but the problem is people will use it for tabs, and for multi-page pages that really should just be a big page with some styles to show/hide sections |
| 09:35 | <Hixie> | not sure how to design the feature so it's not misused |
| 09:35 | <krijnh> | I think I would.. |
| 09:36 | <krijnh> | Tabs you don't want to see aren't relevant, right? :) |
| 09:46 | <krijnh> | Hixie: Would children of irrelevant elements show up in the DOM? |
| 09:47 | <Hixie> | tabs are just a way of re-rendering a group of <fieldset>s so that only one of them is rendered -- the other tabs are just as relevant, they're just not shown |
| 09:47 | <Hixie> | yes, the DOM would be unaffected |
| 10:58 | Hixie | reads the xhtml2 logs and flags some fun lines |
| 11:01 | <krijnh> | From yesterday? |
| 11:01 | <Hixie> | the latest logs, whatever that is |
| 11:39 | <krijnh> | zcorpan: I included a current timestamp on the logs |
| 11:40 | <zcorpan> | krijnh: great |
| 11:55 | <zcorpan> | i have serious trouble telling relatives and friends about what i am to work with at opera :( |
| 11:56 | <zcorpan> | they don't know what test cases are, they don't know what html5 is, some don't even know what a browser is |
| 11:56 | <zcorpan> | if i go "i'll write test cases for html5" they usually go @_@ |
| 12:01 | <krijnh> | What's wrong with people going @_@ ? :) |
| 12:01 | <zcorpan> | they won't stop bugging me until they understand |
| 12:02 | <krijnh> | I'm sure you're able to explain it :) |
| 12:02 | <zcorpan> | yeah, but it takes effort... it's not like "i work at the post office" |
| 12:06 | <zcorpan> | it goes like "you know when you browse the web, you see web pages?", "oh yep", "the browser receives html code so that it can render the page", "oh yep", "for that to work the browser vendor has to implement html", "what's implement?", "programming the browser in a way so that it can handle the code", "oh yep", "so *i* will create test cases for html so that the programmers get things right", "right", "comprendo?", "no" |
| 12:07 | <krijnh> | "Okay, in that case, I work at the post office" |
| 12:07 | <zcorpan> | tempting |
| 12:08 | <krijnh> | "Ah, so you're a web designer?" |
| 12:08 | <krijnh> | That's what I get most of the time |
| 12:08 | <zcorpan> | yeah i got that too |
| 12:08 | <zcorpan> | although i am a web designer, it's not what i'll do at opera |
| 12:08 | <krijnh> | "No, I try to make sites for blind people, although I don't know anybody who's blind" |
| 12:09 | <krijnh> | Btw |
| 12:09 | <krijnh> | "The a element must not be empty." <-- does that mean <a name="foo"></a> is non conforming? |
| 12:09 | <zcorpan> | or well, i don't design, just usnig the term |
| 12:09 | <zcorpan> | krijnh: correct |
| 12:09 | <krijnh> | Hmm |
| 12:09 | <zcorpan> | <a name> isn't either |
| 12:09 | <zcorpan> | in the first place |
| 12:10 | <krijnh> | But it's used a lot |
| 12:10 | <zcorpan> | so? |
| 12:10 | <zcorpan> | this has nothing to do with ua conformance |
| 12:11 | <webben> | um... why has <a name="foo"></a> been made non-conforming?\ |
| 12:11 | <webben> | that's a perfectly good way of making anchors that work cross-browser |
| 12:12 | <zcorpan> | id="" has worked too for the past 10 years afaict |
| 12:12 | <zcorpan> | only not in nn4 |
| 12:12 | <krijnh> | It didn't in Opera a while ago |
| 12:12 | <zcorpan> | what was that, opera4? |
| 12:12 | <webben> | zcorpan: also, not in JAWS earlier than 4.51 |
| 12:12 | <krijnh> | zcorpan: No, 7 |
| 12:13 | <zcorpan> | krijnh: you're kidding, right? |
| 12:13 | <krijnh> | No, wait |
| 12:13 | <krijnh> | http://krijnhoetmer.nl/stuff/html/jump-inside-div/ didn't work in Opera once, and I'm not using Opera since version 4 |
| 12:14 | <krijnh> | But that probably something different :) |
| 12:14 | <krijnh> | *certainly |
| 12:14 | <zcorpan> | webben: right... you can still use html4 if you need to support legacy uas :) |
| 12:16 | <zcorpan> | not that i'm opposed to <a name> though |
| 12:16 | <zcorpan> | if you think it should be allowed then bug the list :) |
| 12:16 | <krijnh> | I don't think it should |
| 12:16 | <webben> | i'm just wondering why it was suddenly disallowed |
| 12:16 | <krijnh> | It's probably written somewhere |
| 12:17 | <webben> | it just declares perfectly good existing content non-conformant AFAICT |
| 12:17 | <krijnh> | That some documents use <a name=foo></a> |
| 12:17 | <zcorpan> | webben: it's disallowed in xhtml1.1 and deprecated in xhtml1.0, probably part of the reason |
| 12:17 | <krijnh> | And what to do with those |
| 12:17 | <krijnh> | webben: So did removing the table summary attribute, for instance |
| 12:21 | <zcorpan> | wow, table summary probably shouldn't have been removed |
| 12:22 | <krijnh> | zcorpan: http://krijnhoetmer.nl/irc-logs/whatwg/20070416#l-118 |
| 12:23 | <hsivonen> | zcorpan: is there AT that makes useful use of the table summary? are sites using it? |
| 12:23 | <krijnh> | Are sites using it? |
| 12:23 | <krijnh> | Yes |
| 12:23 | <zcorpan> | hsivonen: at least jaws uses it |
| 12:24 | <krijnh> | What is AT? |
| 12:24 | <zcorpan> | don't have data about how common it is in the wild but i have seen it being used and i've used it myself |
| 12:24 | <krijnh> | Assistive Technology ? |
| 12:24 | <zcorpan> | krijnh: yes |
| 12:24 | <krijnh> | K |
| 12:24 | <hsivonen> | I wonder if Hixie had a good reason for removing it or whether it is something that hasn't been added yet |
| 12:24 | <krijnh> | Could be AnyThing :] |
| 12:25 | <krijnh> | I'm also using it |
| 12:26 | <zcorpan> | getting information from a table in non-visual media is not a simple task, so getting a summary is useful so you can skip the table but still get the essentials |
| 12:26 | zcorpan | used a summary for http://simon.html5.org/articles/mobile-results |
| 12:28 | <zcorpan> | though, if summary is included in the spec, it should have guidelines about what it's for... "this table has x columns and y rows" is not a useful summary because that information is implied |
| 12:29 | <krijnh> | Shh |
| 12:29 | <krijnh> | ;) |
| 12:29 | <zcorpan> | "this is a layout table" also isn't useful |
| 12:29 | <zcorpan> | :) |
| 12:30 | <krijnh> | I have 5 customers! I cannot and will not break pages for them by removing the auto generated summary ;] |
| 12:30 | <krijnh> | So, I need versioning. |
| 12:30 | <zcorpan> | lol |
| 12:31 | <krijnh> | Hmm, even WCAG (1.0!) says a summary of the complexity of the table can be handy.. |
| 12:32 | <zcorpan> | krijnh: yeah, also see html4 spec |
| 12:32 | <krijnh> | Yep |
| 12:32 | <krijnh> | Summary of purpose and structure |
| 12:32 | <krijnh> | Indeed x cols and y rows is implied |
| 12:32 | <krijnh> | But that wouldn't count as a complex table |
| 12:33 | <krijnh> | Hmm, is it implied btw? |
| 12:33 | <krijnh> | hsivonen: your table integrity checker, can that tell the number of cols and rows in a table, without walking through the entire table? |
| 12:33 | <zcorpan> | if you have a more complex table, then that's even more reason to give a useful summary so that blind people don't have to walk through the entire table to get an idea about it |
| 12:34 | <zcorpan> | krijnh: jaws can state x rows and y columns for tables |
| 12:34 | <krijnh> | Grmbl |
| 12:35 | <krijnh> | zcorpan: I think the summary for your mobile test results is handy for visual UAs as well btw |
| 12:35 | <zcorpan> | krijnh: fair enough, i'll move it out of the table then :) |
| 12:35 | <krijnh> | And keep it in the summary attribute? |
| 12:36 | <zcorpan> | <p>summary<table> (no summary="") |
| 12:36 | <krijnh> | Okay, so now we know why it's dropped ;p |
| 12:36 | <krijnh> | <p>summary<details><table> ;) |
| 12:37 | <krijnh> | <details><legend>summary</legend><table>.. even |
| 12:37 | <zcorpan> | that's not what details is for |
| 12:37 | <krijnh> | I know :) |
| 12:38 | <zcorpan> | summary="" is information that would be redudant for visual media |
| 12:39 | <zcorpan> | hm. i can't connect to any of my servers via ftp anymore. wonder why |
| 12:39 | <krijnh> | I think that a summary is only redundant if it's a very simple table |
| 12:39 | <krijnh> | If it's complex, a summary could be useful for everybody |
| 12:40 | <zcorpan> | ok |
| 12:40 | <krijnh> | I think |
| 12:40 | <krijnh> | Stuff describing the table could be in a caption |
| 12:41 | <zcorpan> | still, a summary for "simple tables" could be useful for blind people (because even a simple table is non-trivial to walk through with a screen reader) |
| 13:15 | <webben_> | hsivonen and zcorpan: Window-Eyes also supports summary and has done for some time: http://www.w3.org/WAI/UA/implementation/eval_win_wineyes411.html |
| 13:19 | <webben_> | It's also worth checking whether tools to distinguish table layouts from data tables use summary as a hint. |
| 13:19 | <webben_> | My guess is they would, but it rather depends on the prevalence of summary abuse. |
| 13:20 | <zcorpan> | webben_: yeah, they do, question is how |
| 13:20 | <zcorpan> | and do we need to spec it |
| 13:20 | <webben_> | zcorpan: I thought HTML5 doesn't spec UA behaviour. |
| 13:20 | <webben_> | we could suggest some behaviours for it |
| 13:21 | <webben_> | I think WCAG probably has a testcase for it |
| 13:21 | <webben_> | one could use that as a base. |
| 13:21 | <zcorpan> | i didn't suggest we spec behaviour |
| 13:21 | <zcorpan> | only an algorithm to determinate whether a table is a layout table or not |
| 13:22 | <webben_> | Ah ... interesting. |
| 13:22 | <webben_> | best ask Aaron Leventhal, as he's looking into integrating such algorithms into Mozilla. |
| 13:23 | <zcorpan> | not sure if it's needed, but it would aid competition in the screen reader space i'd presume, given the web uses layout tables and a screen reader that interprets them all as data tables isn't very useful |
| 13:23 | <webben_> | zcorpan: True. |
| 13:24 | <zcorpan> | also, conformance checkers could use that algorithm to flag layout tables! |
| 13:25 | <zcorpan> | not sure if that's a good thing |
| 13:25 | <zcorpan> | would probably only lead to authors working around the errors |
| 13:25 | <zcorpan> | making the algorithm useless |
| 13:25 | <webben_> | Why would an author bother to do that? |
| 13:26 | <zcorpan> | are you serious? i see *lots* of authors going through hoops to make their pages validate, even if it involves the most redicilous workarounds |
| 13:26 | <zcorpan> | and makes the pages worse |
| 13:26 | <SpookyET> | Hello. |
| 13:27 | <webben_> | hmm ... that would seem to militate against any sort of conformance checking equally |
| 13:27 | <webben_> | not specific to distinguishing layout/data tables. |
| 13:27 | <webben_> | also, /if/ we actually can distinguish layout from non-layout tables, would the use of tables for layout matter half as much |
| 13:27 | <SpookyET> | I've been playing with HTML5. It seems that Opera have implemented quite a bit of it. |
| 13:27 | <zcorpan> | webben_: only where working around the error is simpler than doing the right thing |
| 13:28 | <zcorpan> | SpookyET: yup |
| 13:28 | <webben_> | zcorpan: I suspect the key there is to give people an easier way of laying out pages than misusing tables. |
| 13:29 | <webben_> | maybe (worst-case scenario) giving them an attribute like <table type="layout"> |
| 13:29 | <ajnewbold> | the only reason tables were ever used for layout was poor css support in the early browsers, wasn't it? |
| 13:29 | <SpookyET> | I'm still do not understand what is going on at W3C. Do they care more about their other members than the actual browser makers? |
| 13:29 | <webben_> | ajnewbold: Probably tables were being misused before CSS existed. |
| 13:30 | <ajnewbold> | webben_: heh, well, before CSS even existed, the layout options were severely limited :P |
| 13:30 | <webben_> | SpookyET: Why shouldn't they? |
| 13:30 | <zcorpan> | SpookyET: who are "they"? |
| 13:31 | <webben_> | something I've been wondering is whether you could create a sort of layout markup language to which elements in an HTML file could be mapped |
| 13:32 | <webben_> | perhaps with simple selectors like footer, .photo, #main |
| 13:32 | <webben_> | so that you could get all the ease of laying out with markup |
| 13:32 | <webben_> | but still separate content from presentation |
| 13:33 | <webben_> | in theory XSLT could be used to map between them, but in practice XSLT seems prohibitively hard to use |
| 13:33 | <webben_> | possibly XPath might be some use, but I think element, identifier and class selectors would be easiest |
| 13:35 | <webben_> | and with JS one could actually implement it in existing browsers, much as with WF2. |
| 13:37 | <webben_> | e.g. <view><box halign="center"><row><col select="#main" width="30%"><arrange type="grid" select=".photo"></col><col select="#sidebar"></row><row select="footer"></row></box></view> |
| 13:38 | <webben_> | obviously web designers might well prefer CSS, but I wonder if that would help ordinary authors. |
| 13:40 | <webben_> | <link rel="stylelayout" type="text/slml" media="screen"> could import it |
| 13:40 | <webben_> | that way mobiles could be given different layouts for instance |
| 13:40 | <webben_> | and old browsers wouldn't have to deal with it at all |
| 13:40 | <Lachy> | webben_, I think you're looking for XBL |
| 13:41 | <webben_> | Lachy: I thought XBL used CSS selection? |
| 13:41 | <Lachy> | it does |
| 13:41 | <Lachy> | so? |
| 13:41 | <webben_> | Lachy: So many authors seem to prefer markup. |
| 13:42 | <webben_> | It may just be that nobody has come up with sufficiently sophisticated/intelligent CSS properties |
| 13:42 | <Lachy> | I don't understand, let me finish reading all your messages first |
| 13:42 | <webben_> | e.g. .photo {auto-arrange: grid} |
| 13:43 | <webben_> | even that though, you still have a list of rules not a markup layout |
| 13:46 | <Lachy> | ok, finished. it seems that either css3-layout or XBL <template> could solve the problems you describe |
| 13:47 | <webben_> | ah XBL <template> sounds interesting |
| 13:48 | <Lachy> | you can include whatever markup you like inside it, and style it however you want, and include content from the document in various places |
| 13:48 | <webben_> | that's this thing is it? http://www.w3.org/TR/sXBL/ |
| 13:48 | <Lachy> | no, that's sXBL |
| 13:48 | <Lachy> | try /TR/xbl/ |
| 13:49 | <Lachy> | sXBL is like a predecessor to XBL2 |
| 13:52 | <webben_> | ah okay |
| 13:58 | <webben_> | Lachy: Looks very interesting, especially if it would be possible to concretize some of that into something ordinary authors could use, perhaps in conjunction with a JS lib. Do you know of any implementations or pseudo-implementations? |
| 14:03 | <hsivonen> | krijnh: to tell the number of row and columns in an HTML table, you have to examine the entire table |
| 14:04 | <hsivonen> | krijnh: so no, my table integrity checker cannot tell the number of rows and columns until the entire table has been seen |
| 14:39 | <SpookyET> | <!Doctype html> Since it does not have a version, does it assume that HTML will be backwards compatible forever? |
| 14:40 | <Dashiva> | That's the idea |
| 14:42 | <SpookyET> | It makes sense. You can clean up HTML like XHTML2, but keep the old stuff in the spec in the vintage section. That way, 50 years from now, HTML 3.2 pages can still be displayed assuming that layout engines are well designed and won't be rewritten from scratch. |
| 14:42 | <SpookyET> | Except, IE, of coarse. |
| 14:43 | <Philip`> | It also assumes that even if HTML isn't backwards compatible forever, it's up to that future HTML to add versioning - <!doctype html> doesn't prevent HTML7 from using <!doctype html public "7"> if it turns out that we're wrong now |
| 14:43 | <Philip`> | (Er, maybe that has to be "system" instead?) |
| 14:43 | <SpookyET> | what's with the public and system words? |
| 14:44 | <zcorpan> | Philip`: only if you want to introduce doctype sniffing to xml... |
| 14:44 | <SpookyET> | what's wrong with <!doctype html 7> or the xml style attribute based prolog |
| 14:44 | <Philip`> | Oops, I keep forgetting about XML |
| 14:44 | <zcorpan> | SpookyET: it triggers quirks mode in gecko and webkit |
| 14:44 | <zcorpan> | SpookyET: plus it's not well-formed xml |
| 14:45 | <zcorpan> | (should you care about sniffing in xml) |
| 14:45 | <Philip`> | There's still nothing to stop (X)HTML7 from doing <html version="7"> if it needs to, but people believe we shouldn't encourage that path by doing version="5" now |
| 14:45 | <Philip`> | (I think) |
| 14:46 | <SpookyET> | if you don't have DTDs, the <!doctype syntax> is a relic. <html version=5> makes more sense. |
| 14:46 | <Philip`> | (With public vs system: if I remember correctly, IE treated one as quirks and the other as standards, but I could be wrong about that) |
| 14:48 | <zcorpan> | Philip`: <!doctype html public "7"> and <!doctype html system "7"> both trigger standards mode in ie7 |
| 14:48 | <Philip`> | Hmm, maybe I'm wrong |
| 14:48 | <Philip`> | or maybe it was only IE6, but I didn't think they'd changed that at all |
| 14:49 | <zcorpan> | same in ie6 |
| 14:49 | <Philip`> | Okay, I'm wrong :-) |
| 14:54 | <zcorpan> | it's funny how the css validator warns about all various things. then students have to pass validation without warnings. so they have to add redudant and bogus rules to their style sheets |
| 14:55 | <zcorpan> | like background:inherit when the parent is transparent |
| 14:56 | <zcorpan> | (it doesn't do anything, but it makes the warnings go away) |
| 14:57 | <SpookyET> | I despise those warnings. |
| 14:58 | <SpookyET> | Sometimes, adding background or foreground colours to fix those warnings breaks the style of your page. |
| 14:58 | <SpookyET> | You can't always fix them. transparent or inherit don't always work |
| 14:58 | <zcorpan> | transparent is the default |
| 14:58 | <zcorpan> | if the parent is transparent, then inherit == transparent |
| 14:59 | <SpookyET> | hmm, Sir Bray's page is invalid :-( |
| 15:00 | <zcorpan> | who? |
| 15:00 | <zcorpan> | tim? |
| 15:00 | <SpookyET> | yep |
| 15:01 | <zcorpan> | so? |
| 15:01 | <zcorpan> | :) |
| 15:02 | <SpookyET> | XHTML 1.1 as text/html with 2 validation errors |
| 15:03 | <SpookyET> | It proves that WHATWG are doing is important. If Sir. Bray can't have his own page coded/served according to the spec, how can the rest of us? :-) |
| 15:12 | <mpt> | SpookyET, when does {background: inherit} not work? |
| 15:13 | <mpt> | oh, wait, silly question |
| 15:15 | <mpt> | {background: inherit} has undesirable results when the parent has an image background |
| 15:16 | <zcorpan> | or possibly also a background color |
| 15:16 | <zcorpan> | (if the element is positioned outside its parent or overflows or something) |
| 15:16 | <mpt> | A background color would be fine, the repetition would be a no-op |
| 15:17 | <mpt> | ohhh |
| 15:17 | <mpt> | yik |
| 15:34 | <SpookyET> | mpt: When my menu lists have images in them, and it wants a background-color for the anchor element |
| 15:36 | <zcorpan> | SpookyET: some would add <span>s in between just to get rid of the warning |
| 15:51 | <SpookyET> | zcorpan: No, thank you. |
| 15:51 | <SpookyET> | I write clean code -- http://www.icrhealthcare.com for example |
| 15:52 | <zcorpan> | SpookyET: oh, i didn't suggest you should |
| 15:52 | <zcorpan> | personally i don't find the css validator a useful QA tool at all |
| 15:52 | <zcorpan> | so i don't use it |
| 15:53 | <zcorpan> | i'm just observing that some people *are* going through hoops just to make the warnings go away |
| 15:54 | <SpookyET> | I tried that once or twice. It's not worth it. |
| 15:54 | <SpookyET> | I'm more interested in writing boxed-in css |
| 15:54 | <hsivonen> | zcorpan: I'd like to have a CSS3 Paged Media plus Prince profile for the Oxygen local copy of the CSS validator |
| 15:55 | <SpookyET> | http://www.ksuicehockey.com/css/global-screen.css |
| 15:55 | <zcorpan> | hsivonen: ok |
| 15:56 | <hsivonen> | zcorpan: but with conservatively locked-down profiles, the tool isn't that useful to me |
| 15:57 | <hsivonen> | so I think it is a useful tool in principle, but it needs to grow as fast as CSS |
| 15:57 | <zcorpan> | indeed |
| 15:58 | <SpookyET> | Writing CSS that way doesn't always provide extreme redability, but it makes it very easy to embed applications in your site and referencing your css instead of fully restyling them to match your sites style |
| 15:59 | <zcorpan> | i find the error consoles in browsers more useful to find errors in my style sheets |
| 16:00 | <SpookyET> | firebug |
| 16:01 | <hsivonen> | zcorpan: the validating CSS editor in Oxygen is a really cool idea, but the problem is that when you have enough prince-* properties with squiggly red underline, you stop caring |
| 16:01 | <zcorpan> | yup |
| 16:04 | <SpookyET> | Oxygen has more icons in the toolbars than smallpox victim |
| 16:05 | <zcorpan> | does document.onmessage = function(e) {...} work? or should it be window.onmessage? |
| 16:06 | <SpookyET> | winodw i think, but it's better to use addEventListner |
| 16:06 | <zcorpan> | why? |
| 16:08 | <SpookyET> | You can have more than one listner, and it can't be overriden by document.onmessage = null. |
| 16:10 | <zcorpan> | right. so if i will only use one listener and don't care about it being overridden, window.onmessage would be fine |
| 16:11 | <Philip`> | For cross-document messaging? The spec says it's a bubbling event and it's dispatched on the Document object, so I assume that means document.onmessage would work fine, but I don't know if things bubble from document to window... |
| 16:12 | <zcorpan> | Philip`: events bubble from document to window |
| 16:14 | <SpookyET> | one thing that sucks is that they haven't added event.eventListnersList until DOM3 |
| 16:14 | <SpookyET> | It was stupid to have add/remove with list in DOM2/1, whenever those 2 were added |
| 16:42 | zcorpan | tries to find a good swedish word for "form control" |
| 17:42 | <webben_> | zcorpan: What's wrong with background:transparent when the containing element has a background image? And isn't it the case that background:inherit would do something if a UA (or extension to a UA) applied a default style to (say) a microformat component? |
| 17:42 | <webben_> | it's not obvious to me that such values are pointless |
| 17:49 | <zcorpan> | webben_: don't disagree, i wasn't advocating |
| 17:50 | <webben_> | i thought you said such rules were redundant? |
| 17:51 | <webben_> | maybe I misunderstood |
| 17:51 | <zcorpan> | redundant at best |
| 17:51 | <zcorpan> | harmful at worst |
| 17:52 | <webben_> | that's what i mean, inherit is only redundant when there isn't a default style |
| 17:52 | <webben_> | but the set of default styles is unknown and expanding. |
| 17:52 | <zcorpan> | indeed |
| 21:41 | met_ | found http://www.w3.org/TR/xhtml2/xhtml2-changes.html#a_changes very descriptive |
| 21:43 | <gsnedders> | a very informative appendix indeed :) |
| 21:44 | <SpookyET> | I think the W3C are smoking their own gases. I do not know whom they represent, but I do know they do not represent web developers -- nor browser vendors for that matter. |
| 21:45 | <gsnedders> | the W3C has an idealistic view of the web in a perfect world. |
| 21:45 | <gsnedders> | this != perfect. |
| 21:45 | <Lachy> | that appendix will essentially just repeat the rest of the spec, since nothing is the same as XHTML 1.1 |
| 21:46 | met_ | rofl |
| 21:46 | <gsnedders> | apart from the namespace, possibly. |
| 21:47 | <zcorpan_> | xhtml2 using the xhtml1 namespace is a good way to get xhtml2 even more ignored, if that's even possible |
| 21:47 | <SpookyET> | You have to change your spec to reality, not reality to your spec. |
| 21:48 | <Lachy> | zcorpan_, they did plan to use the XHTML1 namespace. I'm not sure if they've changed their mind about that yet |
| 21:48 | zcorpan_ | has spent some time what reality looks like wrt target="" pointing to id="" or name="" |
| 21:49 | <zcorpan_> | Lachy: yeah, either way, i don't care :) |
| 21:50 | <zcorpan_> | not that i want xhtml2 to fail or anything, i simply don't care, i have other things to care about |
| 21:50 | <Lachy> | yeah, I don't care either. |
| 21:51 | <Lachy> | they rejected my suggestion to fix the XHTML1.1 MIME type issue too, but I'm not even going to bother objecting, since the spec is irrelevant anyway |
| 21:51 | <SpookyET> | Safari have said that they will NOT implement XHTML2. |
| 21:52 | <gsnedders> | almost everyone has :P |
| 21:52 | <SpookyET> | almost? |
| 21:53 | <Lachy> | someone will attempt to implement XHTML2, it just won't be anyone of any importance |
| 21:53 | <SpookyET> | KHTML? |
| 21:54 | <gsnedders> | nobody who is relevant whatsoever. |
| 21:54 | <SpookyET> | neah, KHTML is important for WebKit |
| 21:54 | <gsnedders> | (and calling KHTML is pushing it) |
| 21:55 | <zcorpan_> | i thought there was a project to port webkit to kde and merge the good stuff from both in the process |
| 21:55 | <gsnedders> | there was. |
| 21:55 | <gsnedders> | whether they replace KHTML with WebKit is undecided |
| 21:56 | <gsnedders> | http://dot.kde.org/1152645965/ |
| 21:59 | <SpookyET> | calling KHTML is pushing it? that's the engine's name, isn't it? It stands for KDE HTML. |
| 22:00 | <gsnedders> | I mean, calling KHTML relevant |
| 22:00 | <gsnedders> | it has such a small marketshare. it supporting XHTML2 wouldn't make much difference (not that they plan to) |
| 22:00 | <SpookyET> | KHTML is relevant to WebKit. |
| 22:00 | <SpookyET> | WebKit is relevant to Safari. |
| 22:00 | <gsnedders> | not really at all. |
| 22:01 | <gsnedders> | WebKit is so different now |
| 22:01 | <gsnedders> | remember that WebKit was forked off many years ago |
| 22:02 | <SpookyET> | but they share patches |
| 22:02 | <gsnedders> | there are plenty of parts of the sourcebase which they don't at all. |
| 22:02 | <gsnedders> | as they are completely incompatible in plenty of parts |
| 22:03 | <SpookyET> | KDE 4.0 might change that. |
| 22:04 | <gsnedders> | might. depends on what happens with Unity. |
| 22:05 | <SpookyET> | I like the KDE interface. But, I hate its interface with a passion. |
| 22:06 | <SpookyET> | It's got a billion icons, tabs, and entries. |
| 22:34 | <zcorpan_> | i have 16 test cases and 2 support files to augment an email i've written that i'll send to the whatwg list. ftp doesn't seem to work for me today so i can't upload them. should i zip them and send as attachment? |
| 22:39 | <zcorpan_> | or perhaps someone else can upload them somewhere? |
| 22:39 | <hasather> | zcorpan_: sure |
| 22:41 | <zcorpan_> | hasather: cheers, i'll email them to you |
| 22:41 | <hasather> | ok |
| 22:43 | <zcorpan_> | sent |
| 22:46 | <hasather> | http://hasather.net/test/html/id-vs-name/ |
| 22:46 | <hasather> | oh, and you can write in Swedish to me ;) |
| 22:47 | <zcorpan_> | @_@ right. |
| 22:47 | <hasather> | should I delete text.txt and empty.txt? |
| 22:47 | <zcorpan_> | no, put them in support/ |
| 22:47 | <hasather> | ok |
| 22:48 | <hasather> | ahh, sorry, they were part of the tests of course |
| 22:48 | <zcorpan_> | :) |
| 22:53 | <zcorpan_> | there |
| 23:41 | <zcorpan_> | "Simple animation support: Flash makes creating animations extremely easy. Doing the same thing in anything Free (HTML, SVG, even Gtk) requires being a good code monkey. The example above required NO coding." -- http://www.advogato.org/person/company/diary.html?start=39 |
| 23:42 | <zcorpan_> | thus, we need authoring tools for canvas or svg animations |
| 23:42 | <zcorpan_> | probably svg is more suitable for animations |
| 23:56 | <zcorpan> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010975.html where did that leading space in the table come from? |
| 23:56 | zcorpan | ponders |