| 08:24 | <annevk> | Flex is open source now... |
| 08:25 | <annevk> | Product competition: Company A does C. Really big company B starts doing C as well. A makes their version of C open source. |
| 08:28 | <virtuelv> | annevk: well, I don't really think Really big company B will do the same |
| 09:36 | <hsivonen> | annevk: whoa! URL to Flex announcement? what about Flash player? |
| 09:36 | <annevk> | http://labs.adobe.com/wiki/index.php/Flex:Open_Source |
| 09:36 | <annevk> | (not sure about announcements) |
| 09:36 | <annevk> | (not sure about Flash either) |
| 09:36 | <annevk> | MPL for those who care |
| 09:37 | hsivonen | hopes they mean the tri-license like Dirac when they say MPL |
| 09:38 | <hsivonen> | annevk: thanks |
| 09:38 | <annevk> | not sure about that |
| 09:39 | <annevk> | but i didn't investigate much |
| 09:39 | <hsivonen> | considering that Flash player in itself is not sold, Flash benefits from maximum deployment, MS is doing Silverlight and GNU Gnash is getting serious, it would make sense to open-source Flash Player |
| 09:39 | <annevk> | you are mistaken |
| 09:39 | <annevk> | Flash is sold |
| 09:40 | <hsivonen> | annevk: the player? to handset makers? |
| 09:40 | <annevk> | yes, yes |
| 09:41 | <othermaciej> | so what exactly does Flex do? |
| 09:42 | <hsivonen> | othermaciej: dunno exactly. looks like a Flash app development kit. |
| 09:42 | <othermaciej> | but it has a markup lanaguage |
| 09:42 | <othermaciej> | and isn't just the normal flash authoring |
| 09:42 | <othermaciej> | afaik |
| 09:43 | <hsivonen> | hmm. looks like they are releasing parts that their Flex customers would see and build on anyway |
| 09:44 | <krijnh> | MXML! |
| 09:44 | <othermaciej> | corporate-driven open source is hard |
| 09:44 | <annevk> | WebKit is not? |
| 09:45 | <annevk> | or Mozilla for that matter... or do you mean something else? |
| 09:46 | <othermaciej> | WebKit and Mozilla are hard, yes |
| 09:46 | <othermaciej> | and I think Adobe has less clue about how to run an open source project |
| 09:46 | <krijnh> | So now we can all use Flex for free? |
| 09:48 | <hsivonen> | krijnh: only the libs and the compiler, it seems. The IDE will stay proprietary |
| 09:48 | <krijnh> | We can write MXML ourselves, don't we? :) |
| 10:47 | <met_> | my friend David Majda prepared 5 > 2 wallpapers http://whatwg.majda.cz/wallpapers/ |
| 10:48 | <annevk> | lol, deployed |
| 10:49 | <met_> | my destop already has it 8-) |
| 10:49 | <met_> | there is also svg original |
| 11:05 | <a-ja> | hsivonen: ping |
| 11:50 | <Lachy> | www-html is just getting funnier every day :-) http://www.w3.org/mid/FBABED17-C3FA-4AB8-8942-4BD169FE298A⊙nc |
| 11:51 | <nickshanks> | hilarious isnt it? |
| 11:52 | <Lachy> | his argument is self defeating |
| 11:53 | <Lachy> | "... and moreover, that [versioning] cannot be retro-actively be applied to an extant format." |
| 11:53 | <nickshanks> | his = "Philip & Le Khanh" or me? |
| 11:53 | <annevk> | you, I think |
| 11:53 | <Lachy> | oh, that's you! Yes, your argument :-) |
| 11:53 | <krijnh> | lol |
| 11:53 | <annevk> | but I'm not sure Lachy realized that |
| 11:53 | <annevk> | right |
| 11:53 | <Lachy> | I didn't notice the name on the email |
| 11:54 | annevk | guessed it by the link Lachy pasted |
| 11:54 | <annevk> | users don't blame sites very often |
| 11:54 | <annevk> | they are not actually aware that sites are the problem |
| 11:55 | <zcorpan> | really? |
| 11:55 | <nickshanks> | then make users aware "This website is broekn, it's not an MSIE probelem" |
| 11:55 | <zcorpan> | i hear general complaints about sites sucking or not working all the time |
| 11:55 | <Lachy> | nickshanks, attempting to introduce draconian error handling like you suggest into HTML5 simply wouldn't work, even if it were a good idea |
| 11:55 | <nickshanks> | gah, can't spell :) |
| 11:57 | <nickshanks> | whilst it doesn't have to prevent the site for being displayed, it helps if it is inconvenient for the owners and preferably insults them soehow |
| 11:57 | <Lachy> | but your solution affects the end users, not just developers |
| 11:57 | <annevk> | sounds lovely |
| 11:58 | <Lachy> | give developers tools and browser extensions that notify them of such errors, but don't inflict such errors upon unsuspecting users |
| 11:59 | <annevk> | halting problem makes lots of errors unlikely to be catched anyway |
| 11:59 | <Lachy> | a lot of errors can be caught by tools, though |
| 12:00 | <annevk> | sure |
| 12:00 | <nickshanks> | develoeprs shouldn't need seperate rools |
| 12:00 | <zcorpan> | wow, first spam since we modified the register page |
| 12:00 | <zcorpan> | in the forums |
| 12:00 | <annevk> | nickshanks, what do you mean with separate? |
| 12:00 | <Lachy> | nickshanks, end users don't need developer tools in their browsers |
| 12:01 | <annevk> | people should make it more clear I think that quirks/standards is just an if else switch at some specific places in the code |
| 12:01 | <nickshanks> | the browser *should* inconvenience users, or at least make it clear to them that the owners of the website are stupid |
| 12:01 | <annevk> | not an if else switch for the entire rendering engine |
| 12:01 | <nickshanks> | then the website owners will be inundated with complaints, and they will fix it! |
| 12:01 | <annevk> | nickshanks, maybe in nickshanks pipe dream land |
| 12:02 | <Lachy> | nickshanks, why? You won't help anyone, just inconvenience users and tech support staff |
| 12:02 | <annevk> | handling errors is pretty trivial anyway |
| 12:02 | <nickshanks> | for 1 day, yes, then once the error is corrected there won't be a problem anymore |
| 12:02 | <annevk> | errors are not really the problem |
| 12:03 | <annevk> | the problem is browser sniffing |
| 12:03 | <nickshanks> | and most importantly, web devs will learn to write better code |
| 12:03 | <annevk> | and browser sniffing we won't get around by silly editing tools because it's needed as long as we don't get better interop |
| 12:03 | <virtuelv> | hm. there is one thing irking me with new elements |
| 12:03 | <virtuelv> | given <unknwonelement><p>Other Element</p></unknownelement> |
| 12:04 | <annevk> | virtuelv, that should give the DOM you want |
| 12:04 | <Lachy> | just look at the kind of nonsense that end users ask when presented with errors they don't understand http://lists.w3.org/Archives/Public/www-html-editor/2007JanMar/0053.html |
| 12:04 | <virtuelv> | annevk: not in IE |
| 12:04 | <annevk> | virtuelv, right |
| 12:04 | <annevk> | that's indeed problematic |
| 12:04 | <annevk> | but workarounds have been found (you made one yourself, no?) |
| 12:04 | <virtuelv> | you get unknownelement, p #text, /unknownelement |
| 12:04 | <nickshanks> | Lachy: well the task of writing error messages that peasants can understand i leave to someone else |
| 12:05 | <virtuelv> | annevk: if you're talking about my DOM autocorrector, that's a horrible, horrible, horrible hack not deemed fit for any consumption |
| 12:05 | <Lachy> | nickshanks, you can't just present an idea and expect someone else to do all the work |
| 12:05 | <annevk> | the idea that things can always be error free is just flawed imo |
| 12:05 | <virtuelv> | it involves recreating the entire DOM where elements whose names start with / occur |
| 12:05 | <annevk> | virtuelv, people have put more horrible hacks in real world usage |
| 12:05 | <nickshanks> | Lachy: i'm happy to do the work if a web vendor will hire me :) |
| 12:06 | <annevk> | if it's such a great idea maybe you should implement it yourself and earn millions... |
| 12:06 | <annevk> | </sarcasm> |
| 12:06 | <Lachy> | you could always write up a detailed proposal, explain the pros and cons of the ideas and do research to support your claims. |
| 12:07 | <nickshanks> | strictness has to be implemented in existing browsers, basically MSIE and Firefox, others can follow later |
| 12:07 | <Lachy> | If you can prove beyond all reasonable doubt that browsers should implement your idea, it might get done |
| 12:07 | <nickshanks> | Lachy: i was hoping the common sense in my argument would be enough |
| 12:07 | <Lachy> | what common sense? |
| 12:07 | <zcorpan> | 98 new messages in one day :| seems it just gets more and more... |
| 12:07 | <annevk> | 98? |
| 12:07 | annevk | wonders if he missed them all |
| 12:08 | <zcorpan> | that's what i'm fetching now |
| 12:08 | <Lachy> | maybe zcorpan's spam filter blocked out some of the more annoying contributors :-) |
| 12:08 | <nickshanks> | Lachy: that if we let web developer continue producing tag soup, and not actively prevent them from reaching their customers until they conform, web developers will continue to output crap HTML 5, 6, 7 etc |
| 12:08 | <zcorpan> | Lachy: if only :) |
| 12:09 | <Lachy> | oh, 1495 mails on public-html this month! |
| 12:09 | <zcorpan> | a 0 decisions made so far, right? |
| 12:09 | <zcorpan> | s/a /and / |
| 12:10 | Lachy | checks his tally |
| 12:10 | <Lachy> | yep, 0! |
| 12:10 | <zcorpan> | now that's productive |
| 12:10 | <annevk> | nickshanks, just like browsers will continue with crap interop for the newer features |
| 12:11 | <annevk> | although <canvas> interop is way better than <object>, to be fair |
| 12:12 | <Lachy> | nickshanks, your argument seems to make the false assumption that all HTML is produced by competent web developers |
| 12:12 | <welly> | lol |
| 12:12 | <nickshanks> | i think going forward vendor interop will be much better than before, the problem lies with HTML authors not realising they are making mistakes because their web browser doesn't yell at them - to many devs, opening the page in IE *is* validation of their efforts |
| 12:13 | <annevk> | nickshanks, having some weird error handling on syntax doesn't help with that |
| 12:13 | <Lachy> | nickshanks, yep |
| 12:14 | <Lachy> | nickshanks, the best we can do is encourage authoring tools to produce better content and promote web standards more among professional web developers |
| 12:15 | <nickshanks> | i disagree: the best we can do is persuade MS that silent recovery from errors is detrimental to both users and IE itself in the longer term |
| 12:15 | <annevk> | that's not the problem with IE |
| 12:15 | <annevk> | the problem is that web authors do browser sniffing |
| 12:15 | <annevk> | (and have to, atm) |
| 12:16 | <nickshanks> | the problem is it's 80% market share? ;) |
| 12:16 | <annevk> | no |
| 12:16 | <Lachy> | how is silent recovery detrimental to users? |
| 12:16 | <annevk> | the problem is lack of interop |
| 12:16 | <annevk> | error recovery is just some silly side debate that's hardly relevant imo |
| 12:16 | <Lachy> | getting interop in browsers for all content, whether it's valid or not, is a much more realisting approach than saying they should reject invalid content |
| 12:17 | <Lachy> | s/realisting/realistic/ |
| 12:17 | <nickshanks> | Lachy: because when a web dev only tests in IE, and doesn't see that he has errors, he won't know that other browsers handle things correctly and what he sees is incorrect |
| 12:17 | <Lachy> | that's why we need interop! |
| 12:17 | <Lachy> | not why we need draconian error handlnig |
| 12:18 | <nickshanks> | i would rather have both |
| 12:18 | <zcorpan> | nickshanks: use xml |
| 12:18 | <Lachy> | and then serialise as HTML5 before sending to the end users |
| 12:18 | <nickshanks> | zcorpan: i can't force the creators of every website I visit to do that |
| 12:19 | <annevk> | you can't force them to use your utopia language either |
| 12:19 | <Lachy> | nickshanks, why do you want to force your development tools and opinions on the creators of every web site |
| 12:19 | <zcorpan> | right. if you bring drocanian error handling to html, how do you force the creators of every website I visit to fix their errors? |
| 12:19 | <Lachy> | how does someone else's broken code affect you? |
| 12:19 | <nickshanks> | not my tools, they can use any tools they like (as long as they are black) |
| 12:20 | <annevk> | you're just being silly |
| 12:20 | <virtuelv> | "nickshanks> Lachy: that if we let web developer continue producing tag soup, and not actively prevent them from reaching their customers until they conform, web developers will continue to output crap HTML 5, 6, 7 etc" |
| 12:20 | <nickshanks> | Lachy: because websites don't work in Safari, but work in MSIE which I can't use |
| 12:20 | <virtuelv> | nickshanks: they will continue outputting crap no matter what we tell them |
| 12:20 | <Lachy> | nickshanks, what does the colour of the tool have to do with anything? |
| 12:20 | Lachy | doesn't understand "as long as they are black" |
| 12:20 | <nickshanks> | virtuelv: you miss my point, it's not what *we* tell them, it's what the browser they test in tells them |
| 12:20 | <virtuelv> | and if we go to draconian error handling, all we do is lose content contributed to the web |
| 12:20 | <annevk> | nickshanks, that has to do with browser sniffing |
| 12:21 | <annevk> | nickshanks, not with IE error correction, most likely |
| 12:21 | <virtuelv> | nickshanks: and I'm saying it won't work |
| 12:21 | <annevk> | you should try to find out what the problem is first |
| 12:21 | <Lachy> | nickshanks, that's to do with lack of interop |
| 12:21 | <annevk> | before screaming you found the perfect solution |
| 12:21 | <nickshanks> | Lachy: it's a refernce to the Model T Ford, , Henry Ford said "You can have any colour you like, as long as it's black." (which was the only colour he offered it in) |
| 12:21 | zcorpan | goes read his mail instead |
| 12:22 | Lachy | suggests that nickshanks join the XHTML2WG, who share similar ideas |
| 12:23 | <annevk> | good point |
| 12:23 | <nickshanks> | it doesn't have to prevent display of the site XML-style, just display enough of an error message that CEOs won't allow their web developers to get away with it |
| 12:24 | <annevk> | IE has done that for quite some time |
| 12:24 | <annevk> | and that has been widely ignored |
| 12:24 | <Lachy> | yes, with javascript errors |
| 12:24 | <Lachy> | and so many sites still have errors |
| 12:25 | <nickshanks> | then it doesn't inconvenience a website's customers enough |
| 12:25 | <Lachy> | why do you want to hurt the customers? |
| 12:25 | <nickshanks> | because that's unacceptable to the people in control |
| 12:25 | <nickshanks> | so they won't let it happen on their site |
| 12:26 | <nickshanks> | (i am mostly thinking of commercial sites here) |
| 12:26 | <Lachy> | browsers will not implement such a user hostile approach |
| 12:27 | <nickshanks> | (since they drive a lot of the money in web development) |
| 12:27 | <nickshanks> | Lachy: that's why it needs to be co-ordinated and mandatory (both for vendors and users) |
| 12:27 | <annevk> | you can't mandate UI |
| 12:27 | <Lachy> | inflicting error messages upon end users is simply unacceptable |
| 12:28 | <annevk> | that browsers have implemented the UI for XML that they did, well... dunno why they did that |
| 12:28 | <Lachy> | unless you have a solution that doesn't involve innocent by-standers, this debate is over |
| 12:28 | <nickshanks> | would you rather limp around on a gangrenous leg for the rest of your life, or have it amputated before it gets infected? |
| 12:28 | <annevk> | I suppose it keeps people away from using XML |
| 12:28 | <nickshanks> | HTML will last for 100 years or more |
| 12:29 | <annevk> | yes, including all old content |
| 12:29 | <nickshanks> | anne: no, wrong |
| 12:29 | <Lachy> | nickshanks, I don't understand your analogy |
| 12:29 | <nickshanks> | most old content gets updated |
| 12:29 | <Lachy> | wrong! |
| 12:29 | <virtuelv> | nickshanks: most content on the web is static |
| 12:29 | <nickshanks> | a few years of hurt between 2008 and 2010 won't matter to people in 2050, but continuing to permit tag soup in perpetuity will |
| 12:30 | Lachy | doesn't think nickshanks understands all the implications of his own ideas |
| 12:30 | <nickshanks> | virtuelv: most content on the web going forward is generated by content management systems |
| 12:31 | <Lachy> | nickshanks, do you have evidence to support that claim? |
| 12:31 | <nickshanks> | updating the CMS to output better code will cause all pages it generates (including old content) to immediatly take on the new code |
| 12:32 | <Lachy> | I can assure you that there is a heck of a lot of content that is not output by a CMS |
| 12:32 | <nickshanks> | Lachy: obviously I haven't collected data from 2050, but lets draw an alalogy from the rail industry |
| 12:32 | <nickshanks> | there used to be many competing gauges of track that were interoperable |
| 12:32 | <Lachy> | nickshanks, I'm asking for evidence from the web, as it is *today* |
| 12:32 | <nickshanks> | they converged on one size |
| 12:33 | <Lachy> | what's your point? |
| 12:34 | <annevk> | so the other problem with your idea about showing an error for <input type=silly> is that we can then never introduce such a control in the future |
| 12:34 | <annevk> | because it would break older clients |
| 12:34 | <nickshanks> | we currently have many websites that use non-interoperable code, i want to get them to converge, rather than have browsers try and handle everything |
| 12:34 | <annevk> | silent error recovery implies a nice extensibility story |
| 12:34 | <Lachy> | nickshanks, pave the cowpaths |
| 12:35 | <annevk> | having silent error recovery for the syntax means the same thing |
| 12:35 | <nickshanks> | annevk: in a versioned document format you can, which is why I advocated versioning along with error display |
| 12:36 | <annevk> | versioning is a very silly idea |
| 12:36 | <annevk> | implementing 38 variants of HTML is just not nice |
| 12:36 | <Lachy> | nickshanks, versioning implies that UAs will implement different processing for each version, and that becomes unworkable because you get an increasing number of versions to maintain |
| 12:36 | <Lachy> | to see how harmful versioning is, see the 11 (or more) incompatible versions of RSS! |
| 12:36 | <nickshanks> | then you can start to drop older versions when they become uncommercial |
| 12:37 | <annevk> | i'd suggest you read a bit more into the subject before suggesting these type of things |
| 12:37 | <Lachy> | and how that led to liberal feed parsers that just don't care |
| 12:37 | <annevk> | nickshanks, drop support for content?! |
| 12:37 | <annevk> | while we can actually support it with a saner extensbility story? |
| 12:37 | <nickshanks> | PDF has versioning, Word has versioning, GIF has versioning, practuically every format under the sun does |
| 12:37 | <annevk> | which is easier for authors, user agents, etc. |
| 12:37 | <annevk> | nickshanks, that doesn't imply it's a good thing |
| 12:37 | <virtuelv> | nickshanks: have you even looked at the three most popular CMSes? |
| 12:38 | <annevk> | Word especially is horrible |
| 12:38 | <virtuelv> | There's not a hint of XML in their toolchain, and its not even possible to plug in to the toolchains |
| 12:38 | <annevk> | to open older versions of Word files in Word 2007 you apparently need to change registry settings to circumvent security warnings |
| 12:38 | <virtuelv> | (That goes for blogger, Movable Type and in particular Wordpress |
| 12:38 | <nickshanks> | virtuelv: only wordpress, which i occasionally fix XHTML bugs on |
| 12:38 | <Lachy> | Word is prohibitively expensive, even for MS, to maintian with support for all those different versions |
| 12:38 | <virtuelv> | wordpress is a cancer |
| 12:39 | <annevk> | no |
| 12:39 | <annevk> | wordpress is development as its typically done |
| 12:39 | <annevk> | and probably much better than that |
| 12:39 | <annevk> | we have to take that into account |
| 12:39 | <annevk> | perfection is not attainable |
| 12:39 | <nickshanks> | virtuelv: but think about this - every site running wordpress can update to the latest version and have better quality HTML applied to all their old content |
| 12:39 | <virtuelv> | nickshanks: patentably false |
| 12:40 | <nickshanks> | uhh, no, that's a fact |
| 12:40 | <Lachy> | ah, no, it's not |
| 12:40 | <virtuelv> | there's bunches of wordpress-based hosting services where the users don't control the installs |
| 12:40 | <nickshanks> | i am not saying every site will, but they could |
| 12:40 | <virtuelv> | besides, upgrading wordpress is applying gold paint to a turd |
| 12:40 | <annevk> | heh |
| 12:40 | Lachy | is tired of this poinless debate |
| 12:40 | <nickshanks> | virtuelv: i'm not aguing about the merits of one CMS over others here |
| 12:40 | <Lachy> | *pointless |
| 12:41 | <virtuelv> | my point is still that "No, CMSes can't easily leverage XML, and in particular the popular end-user ones" |
| 12:42 | <nickshanks> | i'm not talking about XML, just conformant HTML |
| 12:42 | <virtuelv> | that would inflict serious harm on the users of said tools |
| 12:42 | <virtuelv> | which means they would stay with the older versions. |
| 12:42 | <virtuelv> | eod |
| 12:42 | <annevk> | doesn't matter |
| 12:43 | <nickshanks> | how would making their HTML output more conformant cause any harm? |
| 12:43 | <annevk> | checking if something is conforming HTML is mathematically impossible btw |
| 12:43 | <mpt> | nickshanks, if you want Web browsers to switch to draconian error handling, I recommend you take it up with your elected representatives |
| 12:43 | <mpt> | encouraging them to introduce a law requiring that |
| 12:44 | <annevk> | maybe they can solve the halting problem :) |
| 12:44 | <mpt> | because in an unregulated browser market, it will never happen. |
| 12:44 | <nickshanks> | as i have said, draconian error handling is not necessary, just enough to make CEOs prevent their web developers from outputting tag soup |
| 12:44 | <annevk> | i'm still not sure why you think it's a good idea |
| 12:45 | <annevk> | what exactly is the problem we currently have you think would be solved by having this? |
| 12:45 | <krijnh> | Caring developers, and not caring developers |
| 12:45 | <krijnh> | Who cares |
| 12:46 | <annevk> | heh, stevenp promoting XForms on www-html |
| 12:46 | <mpt> | And no specification, whether from the W3C or the WhatWG or anyone else without force of law, can make it happen. |
| 12:47 | <mpt> | (I am not at all suggesting that draconian error handling is a good idea.) |
| 12:47 | <nickshanks> | annevk: two problems: browser interop, and future development of web specs being hindered by backwards compatibility issues (like that blasted alt tag!) i don't subscribe to XHTML2's view of dropping backwards compatibility, i just want it to be easy to maintain going forward. currently it is not |
| 12:47 | <annevk> | alt tag? |
| 12:48 | <annevk> | 1 can be solved by creating testsuites |
| 12:48 | <annevk> | 2 not sure what you mean |
| 12:48 | <annevk> | seems that development of specs is going forward |
| 12:48 | <annevk> | see Web Applications 1.0 |
| 12:48 | <nickshanks> | re alt tag: the fact that img is empty and so cannot have fallback content, thus we're stuck with the alt tag |
| 12:49 | <annevk> | there's no such thing is an alt tag |
| 12:49 | <nickshanks> | oh, bugger |
| 12:49 | <mpt> | That's what I was going to say |
| 12:49 | <annevk> | and the alt attribute works good enough |
| 12:49 | <nickshanks> | attribute :-) |
| 12:49 | <nickshanks> | i meant to say attribute |
| 12:49 | <mpt> | but then I thought, no, Hixie probably knows of a few occurrences of an alt tag :-) |
| 12:49 | <annevk> | heh |
| 12:49 | <nickshanks> | the alt attribute doesn't work good enough at all |
| 12:49 | <annevk> | Maciej proposed that <source> would be named <alt> |
| 12:50 | <annevk> | use <object> |
| 12:50 | <krijnh> | http://www.technorati.com/tag/alt <-- look, an alt tag :p |
| 12:50 | <mpt> | and will have some cheerful factoid such as "<alt> is used 146.2 times more often than <samp>" |
| 12:50 | <nickshanks> | lol @ krijnh |
| 12:50 | <annevk> | no need to debate much about this |
| 12:50 | <annevk> | mpt, hehe |
| 12:51 | <mpt> | nickshanks, the poor fallback for <img> is almost entirely TimBL's fault |
| 12:51 | <nickshanks> | no, it's Marc Anddressen's fault |
| 12:51 | <nickshanks> | as is the "src" attribute. i like vowels damnit |
| 12:51 | <mpt> | nono |
| 12:52 | <nickshanks> | http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html |
| 12:52 | <mpt> | You see, if TimBL hadn't been so worried about people putting pictures of nekkid ladies on the Web, he would have introduced it himself, with a proper fallback model |
| 12:52 | <nickshanks> | oops, one 'd' two 'e's |
| 12:52 | <mpt> | and then marca wouldn't have needed to do it, and so wouldn't have done it hamfistedly |
| 12:53 | <nickshanks> | mpt: yes, but I lay most of the blame at marc's feet |
| 12:53 | <mpt> | History doesn't repeat itself, but it does rhyme: trying to prevent nekkid ladies from appearing on the Web, and trying to introduce draconian (or even partially draconian) error handling on the Web, are both examples of standardistas fighting economic forces |
| 12:54 | <nickshanks> | with hindsight I'm sure TimBL would have created object, image with fallback, video, audio and all the WA 1.0 elements we have now :P |
| 12:54 | <Lachy> | what's this about TimBL being against nekkid ladies on the web? |
| 12:54 | <nickshanks> | i don't blame him for not seeing what the web would become, no-one did |
| 12:55 | <annevk> | <A HREF="..." INCLUDE>See photo</A> is nice |
| 12:55 | <krijnh> | annevk: Nice for? |
| 12:56 | <nickshanks> | i don't think <A INCLUDE> had any more or less merit than <IFRAME> |
| 12:57 | <krijnh> | Ow, duh |
| 12:57 | <krijnh> | annevk: Never mind :) |
| 12:57 | <mpt> | "At a conference, Berners-Lee yelled at Andreessen, telling him that adding images to the Web was going to bring in a flood of new users who would do things like post photos of nude women. 'He was right,' Andreessen now says with a shrug." |
| 12:58 | <mpt> | http://www.usatoday.com/tech/news/2003-03-09-internet_x.htm |
| 12:58 | <nickshanks> | TimBL wouldn't have got a knighthood without internet porn |
| 12:59 | <annevk> | nickshanks, it's the backwards compatible alternative to <img>, <object>, etc. as seen from HTML1 perspective |
| 12:59 | <krijnh> | IE6 wouldn't be here without internet porn.. |
| 12:59 | <Lachy> | heh, that's kind of evidence against Bruce Lawson's theory about TimBL |
| 12:59 | <mpt> | which is? |
| 12:59 | <Lachy> | look it up on brucelawson.co.uk |
| 12:59 | <Lachy> | http://www.brucelawson.co.uk/2005/internet-porn/ |
| 13:00 | <mpt> | oh, found it |
| 13:00 | <mpt> | @#$^%! |
| 13:00 | <zcorpan> | annevk: but doesn't work nice with linked images |
| 13:01 | <mpt> | When HTML5 becomes widely used, remind me to add "m {everything: inherit}" to my user style sheet |
| 13:01 | <mpt> | These retarded sites who think I want them to highlight the Google search terms -- no, that's what Google Cache is for |
| 13:01 | <zcorpan> | mpt: you forgot !important |
| 13:02 | <nickshanks> | i think the "m" element has too short a name, it's not clear enough to people what it does |
| 13:02 | <annevk> | zcorpan, nested <a> |
| 13:02 | <Lachy> | mpt, that's also what Google Toolbar is for, and many other extensions |
| 13:02 | <mpt> | zcorpan, that'd be necessary only if the author set !important too, wouldn't it? |
| 13:02 | <Lachy> | mpt, no |
| 13:02 | <zcorpan> | mpt: no |
| 13:03 | <annevk> | mpt, yes |
| 13:03 | <Lachy> | the order goes user normal -> author normal -> author !imporant -> user !important |
| 13:03 | <Lachy> | doesn't it? |
| 13:03 | <annevk> | no |
| 13:03 | Lachy | should look it up |
| 13:03 | <annevk> | yes |
| 13:03 | <annevk> | user -> author -> author !important -> user !important |
| 13:04 | <Dashiva> | UA -> Author -> User -> Author imp -> user imp |
| 13:04 | <zcorpan> | authors style sheet wins over user stylesheet wins over ua style sheet, regardless of specificity... and !important can't be overridden |
| 13:04 | <Lachy> | annevk, that's what I said |
| 13:04 | <mpt> | ok, I was rusty on that part of the cascade |
| 13:04 | <annevk> | whoa |
| 13:04 | <Dashiva> | You switched user and author normal. I wonder if there are any UA rules with !important |
| 13:04 | annevk | messed it up again |
| 13:05 | <mpt> | though my current USS does use !important |
| 13:05 | <annevk> | Dashiva, there's no such thing as UA style sheet |
| 13:05 | <annevk> | Dashiva, although some UAs do have such a concept |
| 13:05 | <krijnh> | annevk: Don't follow my example to much plz k10x |
| 13:05 | <Dashiva> | Well, even if it's not a stylesheet, they do provide default styles |
| 13:05 | <Lachy> | Dashiva, UA don't have !important rules officially (though FF uses them for things that can't be overridden) |
| 13:05 | <zcorpan> | user style sheet doesn't need to be a style sheet either |
| 13:06 | <mpt> | input[type="file"] {... !important}, I guess |
| 13:06 | <annevk> | krijnh, heh, I got the theory right, but didn't match it accurately against the given case... |
| 13:06 | <Lachy> | Dashiva, you're the one who switch the user and author. annevk and I got it right |
| 13:06 | <annevk> | which is better than the last time I talked about this part of the cascade... |
| 13:06 | <Lachy> | http://www.w3.org/TR/CSS21/cascade.html#cascading-order |
| 13:06 | <Dashiva> | Lachy: Yeah, I noticed just after writing it |
| 13:07 | <Dashiva> | Mixed up user and user agent :/ |
| 13:07 | <annevk> | and more... |
| 13:09 | <annevk> | heh, bac then in 93 they also wanted to generalize |
| 13:09 | <annevk> | afraid of people proposing <aud> next week |
| 13:09 | <nickshanks> | annevk: what are you reading? |
| 13:09 | <annevk> | this thread: http://1997.webhistory.org/www.lists/www-talk.1993q1/0202.html |
| 13:10 | <annevk> | that e-mail contains probably the worst suggestion from an authoring perspective |
| 13:10 | <annevk> | from timbl... |
| 13:10 | <krijnh> | <aud> would be bad cause people could put sounds of nekkid women online ;p |
| 13:10 | <Lachy> | krijnh, accessible porn for the blind! :-) |
| 13:10 | <annevk> | SVG: http://1997.webhistory.org/www.lists/www-talk.1993q1/0209.html |
| 13:10 | <annevk> | (or VML, if you wish) |
| 13:11 | <krijnh> | <dialog><dt>Girl</dt><dd>Ah!</dd><dt>Boy</dt><dd>Oeh!</dd><dt>Girl2</dt><dd>Even more ah!</dd></dialog> |
| 13:11 | <krijnh> | Would be great! |
| 13:11 | Lachy | notes that there is actually an accessible porn site ;-) |
| 13:11 | <Lachy> | http://www.brucelawson.co.uk/index.php/2006/blind-accessible-porn/ |
| 13:11 | <krijnh> | I had a possible client mail me for a porn site 2 weeks ago :] |
| 13:12 | <krijnh> | "Cause I knew how to make GoogleBot happy" |
| 13:12 | <mpt> | Then there's the porn sites proudly sporting "W3C valid HTML 4.01" and "W3C valid CSS" badges... |
| 13:12 | <krijnh> | I think I should have accepted it an build the first HTML5 porn site ;p |
| 13:13 | <nickshanks> | krijnh: i'll do it, i need some work |
| 13:13 | <Lachy> | zcorpan, you should make an Valid HTML5! logo specifically for porn sites. (replace the cat with something slightly more appropriate) |
| 13:13 | <krijnh> | nickshanks: he hasn't mailed me back since :) |
| 13:13 | <krijnh> | Yeah, replace it with a pussy |
| 13:13 | <Lachy> | lol |
| 13:13 | <nickshanks> | send him another email for me |
| 13:14 | <nickshanks> | there's a pussy in the corner of ln.hixie.ch |
| 13:14 | <krijnh> | Ow, crap, this chat is logged in public ;] |
| 13:14 | <krijnh> | nickshanks: That's a cat |
| 13:14 | <Lachy> | nickshanks, that's the cat used on the Valid HTML5 logo already |
| 13:14 | <nickshanks> | replace it with a WebKitten ? |
| 13:15 | Lachy | notified twitter users of our discussion ;-) |
| 13:16 | <mpt> | -cringe- |
| 13:17 | <mpt> | Oh no, Lachy prefers Vegemite to Marmite -- we must now be sworn enemies |
| 13:18 | <Lachy> | mpt, yes |
| 13:18 | annevk | vaguely recalls he dislikes both |
| 13:18 | <nickshanks> | well he's an aussie, right? |
| 13:18 | <Lachy> | nickshanks, yes |
| 13:19 | <mpt> | So that's what this Twitter thing is |
| 13:19 | <nickshanks> | vegermite is the national food |
| 13:19 | <Lachy> | annevk, did you remember to buy a pack of tim tams and a jar or vegemite before you left Aus? |
| 13:19 | <mpt> | I just spent half a minute trying to figure out why people use it |
| 13:19 | <nickshanks> | (Lachy: it was a rhetoriccal question ;-) |
| 13:19 | <annevk> | Lachy, I got the cookies |
| 13:19 | <annevk> | Lachy, marcos gave them |
| 13:20 | <Lachy> | cool |
| 13:20 | <nickshanks> | i think twitter is some "listen in to everyone's conversations all over the world thing, because one IRC channel at a time is not enough for most people" |
| 13:20 | <annevk> | Lachy, I also got two toy animals (wonbat(sp?) and platypus) and a boomerang... |
| 13:20 | <annevk> | not sure what to do with those, but they looked funny |
| 13:21 | <Lachy> | *wombat |
| 13:21 | <annevk> | right |
| 13:21 | <mpt> | ... And then I realized "ah, the same reason people write Weblogs, but worse" |
| 13:22 | <mpt> | Wow, Guido van Rossum chimed in on the "proposed new tag: IMG" thread |
| 13:22 | <mpt> | small world |
| 13:22 | <nickshanks> | who's he? |
| 13:23 | <annevk> | python |
| 13:23 | <nickshanks> | he's a snake. gotcha. |
| 13:23 | <mpt> | ... bdfl |
| 13:24 | <mpt> | http://en.wikipedia.org/wiki/Guido_van_Rossum |
| 13:25 | <mpt> | annevk, iirc when British zoologists first received a sample of a platypus they thought it was a hoax |
| 13:26 | <mpt> | http://www.museumofhoaxes.com/platypus.html |
| 13:26 | <nickshanks> | heh, not surprising! what would you have thought? |
| 13:28 | <annevk> | first time I heard about the animal was at http://www.ragingplatypus.com/ |
| 13:28 | <annevk> | "Raging Platypus - Geeks drink it for breakfast" |
| 13:28 | <nickshanks> | didn't you get taught at school about it? |
| 13:29 | <annevk> | don't think so |
| 13:30 | <nickshanks> | odd. being the only mammal to lay eggs it usually gets a mention in Biology classes here in the UK |
| 13:30 | <krijnh> | Blinky Bill! |
| 13:30 | <nickshanks> | btw: that site has an inordinate number of RSS links! |
| 13:31 | <annevk> | that's part of the joke, iirc |
| 13:55 | <annevk> | http://weblogs.mozillazine.org/roadmap/archives/2007/04/openness.html |
| 14:22 | <annevk> | what's the short URL for web forms 2? |
| 14:23 | <Philip`> | http://whatwg.org/wf2/ ? |
| 14:24 | <annevk> | oh, duh |
| 14:24 | annevk | was trying web-forms, web-forms-2, webforms2, web-forms2, etc. |
| 14:24 | <met_> | wf2 ? |
| 14:33 | <zcorpan> | Delivery to the following recipient failed permanently: |
| 14:33 | <zcorpan> | commit-watchers-request⊙lwo |
| 14:33 | <zcorpan> | hm |
| 14:35 | <zcorpan> | confirming the subscription by following the link worked though |
| 14:37 | <Philip`> | http://lists.w3.org/Archives/Public/public-xhtml2/2007Apr/0032.html seems to be considering the same kind of use case as http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010800.html |
| 14:42 | <annevk> | zcorpan, was reported on the list |
| 14:42 | <zcorpan> | Hixie: "We have three lists:" s/three/four/ |
| 14:42 | <zcorpan> | annevk: yeah noticed |
| 14:43 | <zcorpan> | fwiw, "+1" to http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/011070.html |
| 14:44 | <Lachy> | yeah, I somewhat agree with that too |
| 14:44 | <annevk> | except for requiring a particular UI, sure |
| 14:44 | <Lachy> | perhaps the pragmatic decision is to make it conforming and just let UAs disable it (like they already do) |
| 14:45 | <Lachy> | disabling target=_blank is definately easier than disabling window.open |
| 14:45 | <zcorpan> | indeed |
| 14:45 | <Philip`> | zcorpan: Or, for improved ease of future extensibility, s/three/several/ |
| 14:45 | <Lachy> | although I disable both, having .open() disabled causes problems on a few sites |
| 14:51 | <zcorpan> | annevk: seems firefox does "<html><body marginheight="0" marginwidth="0"><embed type="application/x-shockwave-flash" src="foo" name="plugin" height="100%" width="100%"></body></html>" (no HEAD) |
| 14:52 | <annevk> | wow, why name and type? |
| 14:52 | <zcorpan> | don't ask me :) |
| 14:53 | <annevk> | Opera uses style= for the <body> margin stuff |
| 14:53 | <annevk> | not that it matters |
| 14:57 | <annevk> | krijnh, http://krijnhoetmer.nl/stuff/html/input-type-image-value/ WF2 actually mandates that behavior... |
| 14:57 | <annevk> | krijnh, from MSIE |
| 14:57 | <annevk> | (and Opera) |
| 15:01 | <zcorpan> | krijnh: aren't the images presentational? |
| 15:02 | zcorpan | thought type=image was for server side image maps... but acknowledges that buttons are hard to style in some browsers |
| 15:02 | <Philip`> | krijnh: The "unobtrusive JavaScript" is a little obtrusive since the button looks like a button momentarily before it's replaced - could it be hidden with CSS before it's rendered to avoid the flash? |
| 15:04 | <zcorpan> | annevk: speaking of which, if a form control is replaced with an image with css3 generated content, but images are disabled, shouldn't the button be rendered as normal? opera renders it like an <img> without an alt attribute |
| 15:05 | <zcorpan> | annevk: your blog is a good test case for that |
| 15:07 | <annevk> | per the definition of 'content' that's not part of css3-content but will be at some point, yes |
| 15:07 | <annevk> | iirc |
| 15:09 | <zcorpan> | should i file a bug? |
| 15:10 | <annevk> | we have one |
| 15:10 | <zcorpan> | ok |
| 15:13 | <krijnh> | Back |
| 15:15 | <zcorpan> | http://www.robertnyman.com/2007/04/26/geek-meet-may-2007-html-5-and-xhtml/ |
| 15:17 | <annevk> | have fun |
| 15:17 | <zcorpan> | :) |
| 15:18 | <krijnh> | annevk: so.. what do you mean? |
| 15:19 | <annevk> | krijnh, I mean that what IE does is correct |
| 15:19 | <krijnh> | zcorpan: they probably are |
| 15:19 | <annevk> | krijnh, and that Firefox and Konquerer etc. are wrong |
| 15:19 | <annevk> | per the current specs |
| 15:19 | <krijnh> | annevk: i know |
| 15:20 | <annevk> | okay |
| 15:20 | <krijnh> | But that's what makes it hard to use :0 |
| 15:20 | <krijnh> | Or better yet, unusable |
| 15:20 | annevk | goes back to figuring out what the tag name productions are for XML 1.1 |
| 15:20 | <zcorpan> | krijnh: usable for it's intended purpose or for presentational purposes? :) |
| 15:21 | <krijnh> | Usable as in, imho, the nicest solution :) |
| 15:21 | <krijnh> | Philip`: That's possible I think |
| 15:21 | <krijnh> | Philip`: But JS has to hide it in some way |
| 15:22 | <annevk> | so it seems that XML 1.1 pretty much allows any character |
| 15:22 | <annevk> | awesome |
| 15:22 | <krijnh> | zcorpan: How would you do it? |
| 15:23 | <zcorpan> | krijnh: <input type=submit name=option value=Edit> ... input[value=Edit] { content:url(edit.png); } |
| 15:24 | <krijnh> | That'd be cool |
| 15:24 | <zcorpan> | works in opera |
| 15:24 | <krijnh> | Even though my very few customers don't use Opera that much |
| 15:24 | <krijnh> | I know ;) |
| 15:24 | <krijnh> | Had to find a way to fix up http://qontent.nl/_img/screenshots/paginas.png |
| 15:25 | annevk | is amazed with Eliotte Harold |
| 15:25 | <annevk> | the guy with double l |
| 15:26 | <annevk> | guess I had too many silly assumptions about some XML people |
| 15:27 | <MikeSmith> | annevk - for instance? |
| 15:28 | MikeSmith | is also amazed by EHR sometimes, though maybe not for same reasons as annevk |
| 15:29 | <annevk> | he's promoting it where I thought he would find HTML5 quite a silly adventure |
| 15:29 | <MikeSmith> | who knows, maybe he did |
| 15:30 | <MikeSmith> | and maybe he changed his mind after actually reading the spec |
| 15:30 | <krijnh> | annevk: assumptions are the mother of all fuckups ;) |
| 15:30 | jdandrea | is late to the chat. Link for EHR? |
| 15:30 | <Philip`> | Maybe he dislikes the HTML5 serialisation but likes the rest of it? |
| 15:30 | <MikeSmith> | Elliotte Rusty Harold |
| 15:30 | <annevk> | jdandrea, see whatwg⊙wo |
| 15:30 | <jdandrea> | reading it now in fact - thx |
| 15:30 | jdandrea | is prolly not caught up - will keep at it ... |
| 15:31 | <Philip`> | (given that he mentioned in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-April/010954.html being very pro-XHTML) |
| 15:31 | <MikeSmith> | not saying that it's necessarily so for his case, but people do change their minds about things sometimes |
| 15:32 | <annevk> | Philip`, ah right, I guess he's still pro XHTML |
| 15:33 | <MikeSmith> | is that XHTML in the sense of well-formed XML serialization of HTML, or XHTML as in the XHTML 1.1/2 |
| 15:33 | MikeSmith | reads and sees now |
| 15:33 | <annevk> | former |
| 15:35 | MikeSmith | wonders how many people might change their minds about the webapps/HTML5 spec if they actually took time to read it |
| 15:36 | <Philip`> | Are you only considering people who currently object to it, or also the people who currently think they like HTML5 but haven't actually read much of it? :-) |
| 15:36 | <krijnh> | Hehe |
| 15:37 | <MikeSmith> | heh. the former, actually |
| 15:37 | <MikeSmith> | but I guess there probably are a few of the latter as well |
| 15:37 | <MikeSmith> | bible-thumpers on both sides who haven't actually taken the time to read the bible ... |
| 15:39 | <MikeSmith> | but I'd guess that there are far more of the former than latter |
| 15:40 | krijnh | should log IP addresses of people flagging useless lines; http://krijnhoetmer.nl/irc-logs/whatwg/20070426#l-472 |
| 15:40 | <krijnh> | Or dump that feature anyway :/ |
| 15:40 | <Philip`> | At least parts of the bible don't keep getting rewritten every few days - it's harder to keep up with the latest version of WA1 |
| 15:41 | <zcorpan> | krijnh: you could perhaps highlight lines that get linked to (if that's possible to do) |
| 15:41 | <MikeSmith> | krijnh - I like that feature. but I guess like every other useful interactive feature, it's open to abuse |
| 15:41 | <annevk> | krijnh, i'd like a checkbox |
| 15:41 | <krijnh> | Easy on the requests people ;) |
| 15:41 | <annevk> | krijnh, the current UI doesn't work at all in my Opera installation |
| 15:42 | <Philip`> | annevk: I think it works if you double-click the non-text part of the line |
| 15:42 | <Philip`> | (at least when I last tried it) |
| 15:42 | <annevk> | yeah, sometimes... |
| 15:42 | <krijnh> | Yeah, I had trouble with that as well |
| 15:42 | <zcorpan> | krijnh: as a compromise you could do all of the above ;) |
| 15:42 | <krijnh> | zcorpan: fair enough |
| 15:42 | <zcorpan> | krijnh: (i was joking :P) |
| 15:43 | <krijnh> | ;) |
| 15:43 | <annevk> | don't tell him |
| 15:43 | <zcorpan> | heh |
| 15:43 | <krijnh> | Next time put it in a <sarcasm> tag(!) then ;) |
| 15:43 | <jdandrea> | LOL |
| 15:43 | <zcorpan> | right, forgot :( |
| 15:44 | <krijnh> | zcorpan: so how would you say that's possible? |
| 15:44 | <annevk> | lets introduce <joke> on April 1 |
| 15:44 | <krijnh> | If there's a referrer that's not the current document and the location.hash is set |
| 15:44 | <annevk> | or would that be too obvious? |
| 15:44 | <krijnh> | Flag that line |
| 15:44 | <krijnh> | Right? |
| 15:44 | <annevk> | yeah |
| 15:44 | <zcorpan> | something like that |
| 15:44 | <zcorpan> | i have del.icio.used a few lines already |
| 15:45 | <annevk> | maybe that should be the only way to mark lines... |
| 15:46 | <annevk> | kind a like page rank |
| 15:46 | <krijnh> | zcorpan: Yeah, I noticed |
| 15:46 | <krijnh> | Hmm |
| 15:46 | <krijnh> | Would be cool |
| 15:46 | <krijnh> | But that flagging should be done with XHR |
| 15:46 | <krijnh> | Err, AJAX, sorry |
| 15:46 | <krijnh> | So that's probably possible by hand anyway :) |
| 15:47 | <krijnh> | zcorpan: your delicious/zcorpan/zcorpan line is so interesting for the rest of the world btw ;) |
| 15:48 | <zcorpan> | who said del.icio.us musn't contain personal stuff? :) |
| 15:48 | <krijnh> | I don't, but using the new fluffy referrer spam technique that line would be flagged :) |
| 15:49 | <zcorpan> | right |
| 15:50 | <annevk> | maybe the if the referring page contains the name of the person who said the message it should not be marked |
| 15:50 | <krijnh> | Riiight |
| 15:50 | <annevk> | (although it should not be unmarked either, of course, if it already is) |
| 15:50 | <krijnh> | What do you think I am? A competent developer or something? |
| 15:50 | <annevk> | it's not like you got something better to do :p |
| 15:50 | <Philip`> | You could have a Bayesian learning network that decides which lines are interesting, given their content and the replies in IRC and any external links to that line |
| 15:51 | <annevk> | oh, +1 |
| 15:51 | <krijnh> | annevk: because I have irc open on one monitor? |
| 15:52 | <zcorpan> | obviously linked to doesn't imply "important" |
| 15:52 | <krijnh> | Nope |
| 15:52 | <zcorpan> | but flagging them as "linked to" (perhaps with a link back) could be nice |
| 15:53 | <zcorpan> | it's not a request, just an idea :) |
| 16:01 | <krijnh> | annevk: checkbox added |
| 16:01 | <krijnh> | Well, somewhat checkboxy |
| 16:02 | <annevk> | cool |
| 16:03 | <Lachy> | krijnh, can you remove the "are you sure?" confirmation for unmarking a line? |
| 16:03 | <krijnh> | No, that's impossible, it will break backwards compat! |
| 16:03 | <krijnh> | Done ;) |
| 16:06 | <krijnh> | I think dynamically adding 1000 checkboxes isn't nice, so this will do |
| 16:06 | <Philip`> | It's odd how the little yellow/red box gets a few pixels taller when you put the mouse over a link on that line |
| 16:07 | <krijnh> | Yeah |
| 16:07 | <krijnh> | In Opera |
| 16:07 | <krijnh> | Oddness removed |
| 16:08 | <zcorpan> | krijnh: you need a version switch then |
| 16:08 | <krijnh> | zcorpan: Perhaps Lachy can tell me about it in a private mail.. |
| 16:09 | <Philip`> | krijnh: Ah, it works more evenly now - thanks :-) |
| 16:11 | <krijnh> | Yeah, with this I dropped support for IE6 |
| 16:11 | <krijnh> | \o/ |
| 16:12 | <MikeSmith> | krijnh - this is not an official request, but given that the /topic for the #html-wg channel references http://krijnhoetmer.nl/irc-logs/ ... |
| 16:12 | <krijnh> | I didn't put it there.. |
| 16:13 | <MikeSmith> | I'm glad it's there... it's just that part about "(for entertainment ;-)" next to the #xhtml channel |
| 16:13 | <Philip`> | krijnh: Add some <!--[if IE]--> hacks to your code |
| 16:14 | <krijnh> | Yeah, I wondered how long it would take for somebody to fall over that ;) |
| 16:14 | <krijnh> | MikeSmith: removed |
| 16:15 | <MikeSmith> | krijnh - cheers |
| 16:15 | <MikeSmith> | perhaps some would say that numbers there speak for themselves ... |
| 16:16 | <MikeSmith> | making the message in a perhaps more subtle way |
| 16:17 | <zcorpan> | krijnh: heh.. a page listing referrers comes up in your list of referrers :) |
| 16:24 | <krijnh> | zcorpan: that .cz page? |
| 16:24 | <zcorpan> | yeah |
| 16:30 | <annevk> | hmm, writing down a parser for XML in ASCII-art is harder than I expected |
| 16:31 | <annevk> | actually, tokenizer |
| 16:32 | <Philip`> | Would Unicode-art be easier? It has lots of nice lines and double-lines and corners and things |
| 16:32 | <krijnh> | You can make hamburgers with unicode! |
| 16:39 | <gsnedders> | a parser in ASCII-art!? |
| 16:39 | <zcorpan> | krijnh: d(*⌒▽⌒*)b |
| 16:39 | <Philip`> | Bonus points if it's a correctly-operating Befunge program as well as a diagram |
| 16:40 | <krijnh> | ?--------? |
| 16:40 | <krijnh> | Bah |
| 16:40 | <krijnh> | Crap client :) |
| 16:41 | <zcorpan> | heh |
| 16:41 | <annevk> | gsnedders, just the various states indented etc. |
| 16:41 | <annevk> | but I stepped away from that |
| 16:41 | <gsnedders> | aaahhhhh. |
| 16:41 | <gsnedders> | sounds saner :) |
| 16:43 | <zcorpan> | Hixie: the first example on irrelevant="", shouldn't <section id="game"> be <section id="game" irrelevant>? |
| 16:48 | <Lachy> | Hixie, typo in that section too "User agents should net render elements that have the irrelevant attribute specified" -- s/net/not/ |
| 16:49 | <nickshanks> | <html irrelevant> |
| 16:50 | <zcorpan> | <!doctype irrelevant> |
| 16:50 | <nickshanks> | doctype is implicitly irrelevent |
| 16:50 | <Lachy> | if only that triggered standards mode, I'd use it :-( |
| 16:51 | <Philip`> | <!doctype html system "irrelevant">? |
| 16:51 | <Lachy> | could use <!doctype html publick "irr |
| 16:51 | Lachy | was too slow |
| 16:53 | <nickshanks> | how about application/html MIME type as the switch to stop supporting quirks mode? |
| 16:53 | <nickshanks> | then you could leave off the doctype and still be in standards mode |
| 16:53 | <annevk> | not backwards compatible |
| 16:54 | <nickshanks> | anne: that's the point |
| 16:54 | <Philip`> | Is it implicit that 'irrelevant' should cause UAs not to render any child elements of the irrelevant element? |
| 16:54 | <annevk> | nickshanks, the point is adding a few bytes to the MIME type which is way harder to change for people to save a few bytes within the document (which is easy to change)? |
| 16:54 | <krijnh> | Philip`: as I understand it, it's like [irrelevant]{display: none;} |
| 16:55 | <annevk> | and besides that making the whole thing backwards incompatible? |
| 16:55 | <annevk> | seems like way more cost than it's worth to me |
| 16:55 | <nickshanks> | but if you're not going to support tag soup browsers anyway, it doesn't really matter |
| 16:56 | <zcorpan> | Hixie: i don't get the second example of irrelevant=""... the second paragraph seems to be fallback, why don't put that as contents of the <video> (and make <video> fallback on error)? |
| 16:56 | <annevk> | if you don't want to play friendly with the web there's always XHTML2 |
| 16:56 | <nickshanks> | what is with you guys keep suggesting that? |
| 16:56 | <Philip`> | I expect XHTML5 will always be rendered in really-standards mode too |
| 16:57 | <annevk> | nickshanks, maybe you should ask yourself? |
| 16:57 | <annevk> | Philip`, yeah |
| 16:58 | <Philip`> | I assume IE will support XHTML(5) at some point, and I assume it'll do it in really-standards mode (since it's not like there's any existing content to break), and if you don't mind backward compatibility then you can just use that instead of a new MIME type |
| 16:59 | <nickshanks> | that's my point, but no-one seems to listen when i say it |
| 16:59 | <nickshanks> | there is no existing HTML 5 content to break |
| 16:59 | <annevk> | the idea of HTML5 is that it's compatible with older UAs |
| 17:00 | <nickshanks> | it will never be |
| 17:00 | <annevk> | the idea is also that UAs implementing HTML5 will automatically support older versions of HTML |
| 17:00 | <annevk> | as in, no versioning |
| 17:00 | <nickshanks> | that is achievable |
| 17:00 | <nickshanks> | but mosaic will never support canvas |
| 17:00 | <nickshanks> | or any other new element |
| 17:00 | <annevk> | compatible does equal support |
| 17:00 | <annevk> | does not* |
| 17:00 | <annevk> | oops |
| 17:01 | <annevk> | Mosaic will render the fallback content |
| 17:01 | <nickshanks> | i'm not suggesting we change anything that makes mosaic unable to parse the document |
| 17:01 | <krijnh> | And it will render irrelevant elements :) |
| 17:01 | <nickshanks> | like replace <a> with [a] |
| 17:01 | <annevk> | (there may be exceptions to this I suppose, <event-source> isn't really backwards compatible at all, but there's no need for it to be) |
| 17:02 | <annevk> | you're suggesting something that will make Mosaic crash or maybe offer a download dialog |
| 17:02 | <annevk> | for no real benefit |
| 17:03 | <annevk> | krijnh, what do you mean? |
| 17:03 | <nickshanks> | well mosaic won't accept application/html so it will get the text/html version |
| 17:03 | <annevk> | you want to author two versions? |
| 17:03 | <krijnh> | annevk: I think it won't know about the irrelevant attribute? |
| 17:03 | <nickshanks> | if i care about old clients |
| 17:03 | <annevk> | to save <!doctype html> in one?! |
| 17:03 | <annevk> | please... |
| 17:03 | <annevk> | krijnh, oh, duh |
| 17:03 | <nickshanks> | no, you are not understanding |
| 17:03 | <annevk> | krijnh, didn't get that |
| 17:04 | <nickshanks> | stop thinking in terms of now |
| 17:04 | <nickshanks> | and think in terms of 2025 |
| 17:04 | <krijnh> | annevk: Np, I don't the irrelevant attribute either :) |
| 17:04 | <krijnh> | *don't get even |
| 17:04 | <annevk> | nickshanks, i don't see the point of breaking backcompat then either |
| 17:04 | <nickshanks> | do you really still want to be stuck supporting all the crap that was in HTML 3.2 that far ahead? |
| 17:04 | <annevk> | nickshanks, yes |
| 17:04 | <zcorpan> | nickshanks: yes |
| 17:04 | <annevk> | nickshanks, that's the whole point of HTML5 |
| 17:05 | <annevk> | the other option is XHTML2 |
| 17:05 | <annevk> | it has been a conscious decision to not break backcompat |
| 17:05 | <annevk> | if we expect to do that anyway in 20 years we might as well do it now |
| 17:06 | <nickshanks> | but it's not possible to both retain backwards compat and add conflicting features without a switch of some kind |
| 17:06 | <nickshanks> | either doctype, mime type or something else |
| 17:07 | <annevk> | we won't add conflicting features |
| 17:07 | <annevk> | maybe you should read up on the design principles |
| 17:08 | <nickshanks> | there's no way you can know what will be desired in the future |
| 17:09 | <zcorpan> | nickshanks: if we need conflicting features in the future then we can introduce versioning/new mime type/whatever *then* |
| 17:09 | <zcorpan> | nickshanks: we haven't done so know (afaik) so no need to do so now |
| 17:09 | <zcorpan> | er, s/know/now/ |
| 17:10 | <nickshanks> | well, there is an need for versioning now, as shown by doctype switching |
| 17:10 | <zcorpan> | nickshanks: no, there was a need back when doctype switching was introduced. you're suggesting yet another switch, no? |
| 17:11 | <nickshanks> | that need still exists |
| 17:11 | <annevk> | doctype switching is not versioning |
| 17:11 | <zcorpan> | nickshanks: yes, we're stuck with it and probably will be forever |
| 17:11 | <annevk> | it's a few specific rendering differences that depend on a particular string at the start of the document |
| 17:11 | <nickshanks> | no, because HTML doesn't support versioning so we had to come up with a hack |
| 17:11 | <annevk> | it's mostly versioning for the rendering engine, not HTML |
| 17:12 | <nickshanks> | right |
| 17:12 | <annevk> | it should never have been introduced |
| 17:12 | <nickshanks> | but so is any document version |
| 17:12 | <annevk> | but unfortunately it was |
| 17:12 | <nickshanks> | you don't have a better solution |
| 17:12 | <annevk> | i've no idea what you're talking about |
| 17:13 | <nickshanks> | well the application reads a document, and behaves differently depending on what the version number at the start of the document is |
| 17:13 | <annevk> | well yes, as mentioned above, if that's needed we can introduce it |
| 17:13 | <nickshanks> | whether there's one giant switch statement of little if..else's here and there is an implementation detail and not relavent here |
| 17:13 | <annevk> | i don't think we'll ever need it |
| 17:14 | <nickshanks> | i think "we can't be sure we'll never need it, so better to include it and be on the safe side" |
| 17:14 | <annevk> | i don't think quirks mode was needed either, but supposedly it seemed like a good idea back then |
| 17:14 | <annevk> | including it and not letting it have effect will just confuse people |
| 17:14 | <annevk> | as mentioned |
| 17:14 | <nickshanks> | i've worked with plenty of C structs that have version numbers at the start, where the only version was 0 |
| 17:14 | <annevk> | we can always introduce it |
| 17:14 | <annevk> | we don't need to be safe |
| 17:15 | <annevk> | C is not comparable with HTML |
| 17:15 | <nickshanks> | HTML is instructions to be interpreted and cause an effect |
| 17:15 | <nickshanks> | same as any other computer language |
| 17:16 | <hasather> | nickshanks: no, HTML is no programming language |
| 17:17 | <nickshanks> | i don't see the difference |
| 17:20 | <othermaciej> | nickshanks: how many C programs have you seen that declare the version of C they are using at the top of the file? |
| 17:21 | <nickshanks> | the version of C is declared outside of the code files in the IDE |
| 17:21 | <Philip`> | HTML6 can say the default value of the 'version' attribute is '5', and an HTML6 browser will apply that rule to every page it sees. You can't do anything like that in C - a change to the struct's layout won't be picked up by all the existing binary code that uses it, so the version has to be explicit |
| 17:22 | <annevk> | html-wg looks like chaos |
| 17:23 | <othermaciej> | nickshanks: when I type cc myprogram.c at the command line, I don't include a mention of the C version anywhere |
| 17:23 | <nickshanks> | the version of C is declared outside of the code files in the IDE (you may have missed that) |
| 17:24 | <nickshanks> | and if you compile it with a subset or incompatible version, you get errors |
| 17:24 | <Philip`> | The version there is optional - you could run "gcc -ansi" or "gcc -std=c89" |
| 17:24 | <nickshanks> | but it has a default value |
| 17:24 | <Philip`> | but it seems most people don't use either of those, because the language is largely backward-compatible and so you can compile all your code as C99-plus-GCC-extensions |
| 17:25 | <nickshanks> | anyway, i wasn't talking about the version of C (good example, btw) i was talking about the version of some data structure that your app is reading off disk |
| 17:25 | <Philip`> | but when it doesn't work, you can modify the source code, which is not possible with HTML because it's not your source code |
| 17:26 | <othermaciej> | nickshanks: but HTML is a language, not an on-disk binary formatted data structure |
| 17:27 | <annevk> | Philip`, nice comparison; (as opposed to modify we fix the source code) |
| 17:27 | <nickshanks> | but how that language is to be interpreted is not consistent across all versions of HTML |
| 17:29 | <annevk> | it's whatever the latest version says |
| 17:29 | <nickshanks> | mostly due to errors in specs |
| 17:30 | <nickshanks> | anne: but not all UAs follow the "latest version" so you lose your back compat right there |
| 17:30 | <annevk> | no |
| 17:30 | <annevk> | because the latest version is designed with that in mind |
| 17:31 | <nickshanks> | unless it has an error in it |
| 17:31 | <annevk> | in which case that will be pointed out and fixed |
| 17:31 | <nickshanks> | after it has been implemented |
| 17:31 | <nickshanks> | at which point it's too late |
| 17:31 | <annevk> | this also goes for theoretical versioned HTML so I'm not sure what your point is |
| 17:32 | <annevk> | yes, it could also be implemented incorrectly... if that's done and not much breaks it's apparently acceptable |
| 17:32 | <annevk> | languages evolve |
| 17:32 | <nickshanks> | versioning in HTML would basically be about how to recover from mistakes in specs or mistakes in how developers wrote for that version |
| 17:32 | <nickshanks> | so that when it was fixed, you could do it the "old way" when encountering an old file |
| 17:32 | <annevk> | what fixed? |
| 17:33 | <nickshanks> | whatever the original error was |
| 17:33 | <annevk> | the current algorithm is largely compatible with the web |
| 17:33 | <annevk> | it needs more impl experience of course |
| 17:33 | <nickshanks> | usemap in XHTML is a good example |
| 17:33 | <Philip`> | annevk: But evolution requires death, and nobody wants to kill any old HTML content, so HTML can't evolve - it just grows and mutates :-) |
| 17:33 | <annevk> | nickshanks, usemap in XHTML was a bug in the spec |
| 17:34 | <nickshanks> | right |
| 17:34 | <nickshanks> | you can't guarantee that all future versions of HTML won't be bug free |
| 17:34 | <annevk> | and hardly relevant given that 0.00% of the sites out there use XML |
| 17:34 | <nickshanks> | it's an EXAMPLE for god's sake |
| 17:34 | <annevk> | nickshanks, no, you can't |
| 17:34 | <nickshanks> | it could happpen to HTML 5 |
| 17:34 | <annevk> | yes, the current spec is imperfect |
| 17:34 | <annevk> | i don't really see the problem |
| 17:35 | <annevk> | if such a bug is found the bug is fixed |
| 17:35 | <nickshanks> | even if it wasn't, the next version might be |
| 17:35 | <annevk> | specs and implementations require many iterations |
| 17:35 | <othermaciej> | if you make a mistake in the spec, you have a problem |
| 17:35 | <annevk> | Philip`, I'm not sure I agree with that |
| 17:35 | <othermaciej> | if you use versioning to address it, you have two problems |
| 17:35 | <annevk> | Philip`, but I can't really refute it either |
| 17:35 | <annevk> | othermaciej, :) |
| 17:36 | <nickshanks> | if I write a site and put <html version="5.0"> at the top, web browsers will know that i mean b when i write a, and if i put version="5.01" they'll know not to change the meaning |
| 17:36 | <annevk> | browsers will ignore that information... |
| 17:37 | <nickshanks> | then they won't know which I meant and will have to guess |
| 17:37 | <nickshanks> | i, the author, provide the answer so no need to guess |
| 17:37 | <annevk> | i've no idea what you're talking about |
| 17:37 | <annevk> | html will just be interpreted by whatever the latest spec says on the matter |
| 17:38 | <Philip`> | Is the (theoretical) problem only that HTML5 might specify some behaviour, and lots of sites are built to rely on it, then HTML6 accidentally specifies a different incompatible behaviour, but nobody notices the bug and lots of sites are built that rely on it, and then somebody notices and HTML7 is stuck because it'll break half the sites? |
| 17:38 | <othermaciej> | version info is not generally used to switch anything that is based on the spec |
| 17:38 | <nickshanks> | Philip`: yeah, basically |
| 17:38 | <othermaciej> | doctype switching for standards vs. quirks mode is solely about some CSS rendering differences for compatibility |
| 17:38 | <othermaciej> | HTML 2, HTML 3.2 and HTML 4 are all treated the same |
| 17:38 | <annevk> | nickshanks, that's not a realstic scenario though |
| 17:39 | <nickshanks> | i don't see why you're against having a safty net |
| 17:39 | <nickshanks> | +e |
| 17:39 | <annevk> | it's not needed at this point |
| 17:39 | <Philip`> | I would expect that situation to be unlikely, because people will test their HTML6 sites in HTML5 UAs too, and their HTML5 sites in HTML6 UAs, and so somebody will notice the bug soon (before the next version of market-dominant-browser-of-the-day is released) and the spec can be fixed |
| 17:39 | <annevk> | adding things that are not needed is just adding bloat |
| 17:39 | <annevk> | and sets the wrong precedents |
| 17:40 | <nickshanks> | until next year, when you realise, "oh shit, we screwed up there, and now there are two different interpretations floating about, and no way to tell which one is which because we didn't include differentiation" |
| 17:40 | <annevk> | Philip`, implementors will surely notice such an incompatibility |
| 17:40 | <annevk> | nickshanks, if two UAs do something different introducing versioning doesn't help |
| 17:40 | <nickshanks> | Philip`: a lot of people don't test in more than one browser |
| 17:40 | <annevk> | nickshanks, versioning doesn't solve the UA problem |
| 17:41 | <annevk> | how the hell would it solve that?! |
| 17:41 | annevk | has the feeling he's wasting his time here |
| 17:41 | <nickshanks> | sorry, which problem? |
| 17:41 | <annevk> | the problem that two UAs might do different things |
| 17:42 | <nickshanks> | i wasn't talking about two USa, i was meaning two subsequent versions of HTML |
| 17:42 | <nickshanks> | UAs * |
| 17:42 | <Philip`> | The problem of two versioned sites using <html version="5.0.6">, each tested in different UAs that have incompatible behaviour |
| 17:43 | <nickshanks> | cross compatibility on the same version of HTML is not what's being discussed |
| 17:43 | <annevk> | nickshanks, such a thing hasn't occured yet, so i don't really see that as a potential problem |
| 17:43 | <nickshanks> | that's hardly a defence |
| 17:43 | <nickshanks> | and it occured with usemap |
| 17:43 | <annevk> | i think it is |
| 17:43 | <annevk> | XHTML is irrelevant to this discussion |
| 17:43 | <annevk> | there's no usage |
| 17:44 | <annevk> | and people did notice and reported the error |
| 17:44 | <annevk> | the spec was just never fixed |
| 17:44 | <annevk> | fortunately we now have more competent people running HTML |
| 17:45 | <nickshanks> | right, my point is that there was an error, and it could happen again (no matter how competent we are) |
| 17:45 | <Philip`> | Was it reported before any implementations were released that used the incompatible behaviour? |
| 17:46 | <nickshanks> | future HTML developers might also realise they have to break back compat in order to move forward (in which case versioning will be required, instead of just being a reserve parachute) |
| 17:46 | <nickshanks> | Philip: it was reported before the spec was finished, they just said "yeah, so what?" |
| 17:47 | <annevk> | nickshanks, in which case they can introduce versioning then |
| 17:47 | <annevk> | nickshanks, introducing versioning and unnoticely introducing a backcompat change doesn't solve this problem either |
| 17:47 | <annevk> | nickshanks, because UAs won't know the behavior has suddenly changed |
| 17:48 | <nickshanks> | anne: do you not see how having a version might help future UAs resolve a dilemma ? |
| 17:48 | <annevk> | nickshanks, in fact, they won't change their current behavior... |
| 17:48 | <annevk> | nickshanks, I don't think the dilemma will ever occur |
| 17:48 | <nickshanks> | as i said, that's no defence |
| 17:48 | <annevk> | how is it not? |
| 17:49 | <nickshanks> | because you could quite easily be wrong! |
| 17:49 | <annevk> | so could you! |
| 17:49 | <zcorpan> | nickshanks: you still haven't said why we need to introduce it *now*. why can't it be introduced when we find that it is needed (if at all)? |
| 17:49 | <annevk> | and then we've added bloat for nothing and all kinds of other crap |
| 17:49 | <nickshanks> | it should have been in every version of html |
| 17:49 | <zcorpan> | why? |
| 17:49 | <zcorpan> | so far there haven't been a need afaict |
| 17:49 | <Philip`> | You could both be wrong - maybe the future is LaTeX |
| 17:49 | <nickshanks> | so we can drop old elements or change their functionality |
| 17:49 | <nickshanks> | like menu |
| 17:50 | <annevk> | Philip`, LaTeX would presumably not use text/html |
| 17:50 | <nickshanks> | menu in HTML 5 bears no relation to menu in html 1 |
| 17:50 | <annevk> | nickshanks, the upgrade is done in a compatible way |
| 17:50 | <nickshanks> | and in order to retain back compat there is a whole load of unnecessary bloat in the spec |
| 17:50 | <annevk> | versioning doesn't solve that either |
| 17:51 | <zcorpan> | nickshanks: what's the benefit of dropping support for old elements under a new switch but keeping support for them for pages without the switch? it just adds implementation complexity |
| 17:51 | <annevk> | versioning just introduces more bloat |
| 17:51 | <annevk> | so far versioning just introduces more problems as I see it |
| 17:55 | <Philip`> | nickshanks: The goal of the WHATWG work is to be an implementation comparable with current browsers - if the browsers have to implement <menu> in a certain way because content requires it, then the spec will have to do the same, so it can't just drop it and become less bloaty |
| 17:56 | <Philip`> | (i.e. it's necessary bloat, given the requirements which are placed on the spec) |
| 17:57 | <Philip`> | and that seems like quite a fundamental goal, so I don't see it ever being changed within this group |
| 17:57 | <nickshanks> | on another topic: i think it would idea to take the error handling from WA 1 and apply it to a HTML 4.1, so that we have a version of HTML 4 that is interoperable and standardised as such |
| 17:58 | <nickshanks> | whilst leaving all the new stuff for HTML 5 |
| 17:58 | <Philip`> | Like an HTML4-featured profile of the HTML5 spec? |
| 17:58 | <Philip`> | (People don't seem to like profiles that much...) |
| 17:58 | <nickshanks> | whatever you want to call it |
| 17:59 | <annevk> | everything was broken in HTML4 |
| 17:59 | <annevk> | it would still be a lot of work |
| 17:59 | <nickshanks> | now you're exaggerating a little :) |
| 18:00 | <nickshanks> | yeah, it would be work |
| 18:00 | <nickshanks> | but we can get the W3C to do that |
| 18:00 | <annevk> | not really... |
| 18:00 | <annevk> | why? |
| 18:00 | <Philip`> | Is a conformant interoperable HTML 4.2 UA more useful than a non-conformant (because it's missing all the new features) interoperable (because the implemented ones follow the spec) HTML 5 UA? |
| 18:00 | <Philip`> | *the implemented features |
| 18:01 | <zcorpan> | more to the point, what's the benefit of such a spec? |
| 18:01 | <nickshanks> | philip: that would depend on what content you were using, primarily 4.2 or 5.0 sites |
| 18:02 | <nickshanks> | zcorpan: it would (i assume) be out more quickly than HTML 5 and web authors can start using it |
| 18:02 | <nickshanks> | and vendors can follow it |
| 18:02 | <annevk> | you need a testsuite for that |
| 18:02 | <nickshanks> | without haing to implement the rest of HTML 5.0 befor ethey release too |
| 18:02 | <nickshanks> | is one not being written? |
| 18:02 | <annevk> | people are already implementing HTML5 |
| 18:02 | <annevk> | not at lightspeed |
| 18:02 | <nickshanks> | it would be the HTML 5 test suite with new stuff removed |
| 18:03 | <nickshanks> | just a stop-gap measure to sure up HTML 4 interop before HTML 5 arives |
| 18:03 | <annevk> | the best way to get interop is create tests |
| 18:04 | <annevk> | not by creating specs |
| 18:04 | <nickshanks> | well the spec exists 99% already |
| 18:04 | <zcorpan> | nickshanks: why can't UAs just implement a subset of html5, and authors use a subset of html5? i don't see the benefit of having a de jure subset rather than de facto subset for a given point in time |
| 18:04 | <Philip`> | Are the new HTML5 features much easier/harder to implement than the bugfixes for HTML4 features? |
| 18:04 | <annevk> | ... |
| 18:04 | <nickshanks> | okay, alternative plan: create HTML4-compatible tests before the HTML5-only ones |
| 18:05 | <nickshanks> | and forego a version 4.1 spec |
| 18:05 | <zcorpan> | since the subset changes over time, when you're done with your html4 subset the implementations have added support for a number of other features which are part of the de facto subset |
| 18:05 | <zcorpan> | rendering the html4 subset irrelevant |
| 18:06 | <annevk> | Philip`, implementing <canvas> might be easier than fixing some of the bug... patching legacy code can be tricky |
| 18:06 | <Philip`> | nickshanks: But then the early HTML5 implementations would have no tests and wouldn't be interoperable, which wouldn't be good, unless the implementations are held back until the tests are finished (which isn't going to happen, since they're not even waiting for the spec to be finished) |
| 18:06 | <nickshanks> | zcorpan: the tests would never become irrelevent |
| 18:06 | <zcorpan> | nickshanks: did i say that? |
| 18:07 | <nickshanks> | yes you did, a few lines up\ |
| 18:07 | <zcorpan> | i meant the de jure html4 subset of html5 you're advocating, not tests |
| 18:07 | <nickshanks> | i am talking about tests |
| 18:07 | <zcorpan> | oh, sorry |
| 18:07 | <othermaciej> | zakim, unmute me |
| 18:07 | <othermaciej> | doh |
| 18:07 | <zcorpan> | creating tests for a subset of html5 is good |
| 18:08 | <zcorpan> | but doesn't mean we have to create a separate spec |
| 18:08 | <nickshanks> | right |
| 18:08 | <nickshanks> | specs help HTML authors, tests help UA authors |
| 18:08 | <zcorpan> | tutorials help authors |
| 18:09 | <zcorpan> | specs and tests help implementors |
| 18:09 | <Philip`> | Apart from <!doctype html>, I'd expect most HTML5 tests to not be using any new HTML5 features, so they'd work fine for testing HTML4-featured UAs |
| 18:09 | <nickshanks> | tutorials are usually written by people who've read and comprehended a specification first though :P |
| 18:10 | <zcorpan> | nickshanks: right, specs help tutorial authors |
| 18:10 | <nickshanks> | i can't imagine anyone proposing HTML 6 have no spec and just a bunch of tests :) |
| 18:10 | <zcorpan> | and authors who know how to read specs |
| 18:11 | <Philip`> | (Maybe the tests that use new features could just be labelled, rather than intentionally writing tests to a specific subset of the spec) |
| 18:11 | <nickshanks> | i think anyone with a basic grasp of english can read the spec, and if it's well written, understand it |
| 18:11 | <nickshanks> | trouble is not many authors do! |
| 18:12 | <nickshanks> | and even, apparently, some people who write "Lern Yerself HTML Kwik!" type books don't read the spec :-o |
| 18:12 | <Philip`> | Not many authors do have a basic grasp of English? Maybe there should be an official translation of the spec into Chinese :-) |
| 18:12 | <zcorpan> | nickshanks: not really, you have to know about rfc2119 terms and be able to distinguish between what applies to authors or not, and what is normative or not |
| 18:12 | <nickshanks> | Philip: yes, that would be a good idea too |
| 18:13 | <nickshanks> | I think readers SHOULD know about rfc2199 |
| 18:13 | <nickshanks> | but it makes pretty good sense to an english speaker even if they don't |
| 18:14 | <nickshanks> | i would expect most errors on web pages are trivial though, not conceptual |
| 18:15 | <nickshanks> | whether something is normative or not isn't too critical |
| 18:15 | <Philip`> | Someone (can't quite remember who) had some confusion over http://www.whatwg.org/specs/web-apps/current-work/#lists where it says you need comma-only separators to be valid, but the algorithm accepted spaces too |
| 18:15 | <jdandrea> | That was me. |
| 18:15 | <Philip`> | because it's not particularly obvious that the former applies to authors, and the latter should never be looked at by authors and only applies to UAs |
| 18:16 | <jdandrea> | Bingo. |
| 18:16 | <jdandrea> | Of course now when I read it, I grok. :) |
| 18:16 | <jdandrea> | (well, maybe not grok but you get the idea - it makes sense now) |
| 18:17 | <Philip`> | I think that kind of subtlety makes it hard to read the spec properly, even after you can read all the English |
| 18:17 | jdandrea | is reminded of: "It's easy when you know how!" :) |
| 18:17 | <Philip`> | jdandrea: Ah, sorry, I wasn't sure who it was :-) |
| 18:18 | <nickshanks> | should the WA spec wrap implementor only details with a display: none div? |
| 18:18 | <nickshanks> | and have a little button to show them |
| 18:18 | <nickshanks> | it would make it an awful lot shorter for most users! :) |
| 18:19 | <Philip`> | (jdandrea: Also sorry, can't respond to PMs, since I've been too lazy to register on Freenode :-) ) |
| 18:20 | <zcorpan> | nickshanks: might be nice but how would it be done? should Hixie markup everything with classes? |
| 18:20 | <jdandrea> | Philip` - no worries. It's a good example (comma-only separators)! |
| 18:20 | <zcorpan> | nickshanks: or is there a way to programmatically determinate whether something applies to authors or not? |
| 18:20 | <jdandrea> | There was discussion on this at the time of that chat, IIRC. Checking logs ... |
| 18:21 | <nickshanks> | zcorpan: well i'm not sure, i'd have to look at the page's code |
| 18:21 | <zcorpan> | nickshanks: if you figure out a good way, let me know |
| 18:21 | <nickshanks> | even if it has to be done by hand, it won't take as long as writing the spec down in the first place did |
| 18:22 | <nickshanks> | zcorpan: were you the one responsible for the multipage script? |
| 18:22 | <jdandrea> | http://krijnhoetmer.nl/irc-logs/whatwg/20070420 |
| 18:22 | <zcorpan> | nickshanks: no |
| 18:22 | <jdandrea> | Relevant lines: |
| 18:23 | <zcorpan> | nickshanks: i have contributed to the status script |
| 18:23 | <Philip`> | nickshanks: Blame me for that :-) |
| 18:23 | <jdandrea> | zcorpan_: "people asked for a view of the spec that only had the information that applied to authors, i think." Philip`: "Could we add a new HTML element for it? <relevance who="authors"> " zcorpan: "it would be nice but it's hard to do programmatically as it looks now" |
| 18:23 | <nickshanks> | zcorpan: <p>The <dfn id=rules3>rules for parsing a list of integers</dfn> are as follows: |
| 18:24 | <nickshanks> | so it looks like matching on "<dfn id=rules" and taking the enclosing block-level element might work as a stating point |
| 18:25 | <nickshanks> | and why is the webapps spec written in HTML 4 :P |
| 18:25 | <Philip`> | Trying to simply chop out parts of the document would probably be too much of a constraint on the prose if it was going to be precise, and it'd become hard to read and write - a separate author-level not-officially-normative spec may be easier to write |
| 18:26 | <Philip`> | nickshanks: Apparently just because of the tools used to generate it |
| 18:26 | <Philip`> | The multipage one is HTML5, since that has nicer tools ;-) |
| 18:26 | <nickshanks> | fair engough |
| 18:26 | <nickshanks> | -g |
| 18:27 | <Philip`> | (I hope the multipage one is using <nav> correctly - I never really checked what the spec says...) |
| 18:27 | <zcorpan> | nickshanks: ok, but that wouldn't catch very much... if we want to filter out things that don't apply to authors, we have to filter out everything that doesn't apply to authors and find a sane way to do so |
| 18:28 | <nickshanks> | doing it by hand may be boring, but is probably the only way |
| 18:28 | <zcorpan> | Philip`: i think it does |
| 18:28 | <zcorpan> | nickshanks: ok. so who would do it and how exactly? |
| 18:29 | <nickshanks> | probably hixie, and by putting a div around them |
| 18:29 | <nickshanks> | or a class on the <p> |
| 18:29 | <nickshanks> | it need not be hidden at the moment |
| 18:30 | <nickshanks> | but given a new bg colour |
| 18:30 | <nickshanks> | or some such |
| 18:30 | zcorpan | thinks Hixie's time is better spent on other things |
| 18:30 | <nickshanks> | zcorpan: does anyone else have authorship access to that document? |
| 18:31 | <nickshanks> | also, it can wait until the spec gets finalised |
| 18:31 | <zcorpan> | nickshanks: define finilised |
| 18:31 | <nickshanks> | but UA implementation instructions should not be shown by default to HTML authors who just want to learn about this new spec that just got announced. |
| 18:32 | <zcorpan> | agreed, problem is how to do it |
| 18:32 | <nickshanks> | zcorpan: either CR or REC depending on how busy the editor is |
| 18:32 | <nickshanks> | well the alternative is cutting up the document into a UA version and a HTML version |
| 18:33 | <nickshanks> | which would probably take just as long |
| 18:33 | <nickshanks> | (but wouldn't require javascript, so...) |
| 18:34 | <zcorpan> | nickshanks: i was thinking of somehow applying a mask on top of the spec with javascript |
| 18:34 | <Philip`> | I imagine there'd be extra text that probably should be shown only in the author version, not the real-spec version - e.g. the parsing section would be replaced with "you write <tag attr="value">...</tag> but you can skip the closing one on this list of elements, and you have to nest them properly, etc" (but written far better), which (as far as I can tell) is not in the real spec today |
| 18:34 | <nickshanks> | or painting the screen with TippEx |
| 18:34 | <zcorpan> | haven't figured out if or how it would work exactly though |
| 18:35 | <zcorpan> | but perhaps in a similar way as the status markers |
| 18:35 | <nickshanks> | the red fortresses? |
| 18:36 | Philip` | has currently been identifying sentences in the spec by using regexps that match them, which is probably quite fragile and inefficient, but at least it works and doesn't need the spec itself to be modified |
| 18:36 | <zcorpan> | nickshanks: yes |
| 18:36 | <nickshanks> | how would that hide them from potentially confusable HTML newbies? |
| 18:37 | <zcorpan> | nickshanks: you locate the elements that are irrelevant to authors, then hide them with css |
| 18:38 | <nickshanks> | am investingating.... |
| 18:38 | <nickshanks> | okay, so it seems we have code like: |
| 18:38 | <nickshanks> | <h3 id=forms><span class=secno>3.16. </span>Forms</h3> |
| 18:38 | <nickshanks> | <!-- XXX everything in WF2 --> |
| 18:38 | <nickshanks> | <p class=big-issue>This section will contain definitions of the |
| 18:38 | <nickshanks> | <code>form</code> element and so forth. |
| 18:39 | <nickshanks> | so is CSS or JS responsible for inserting the [TBW] bit there? |
| 18:39 | <zcorpan> | nickshanks: look at http://status.whatwg.org/annotate-web-apps.js |
| 18:39 | <nickshanks> | thx |
| 18:41 | <nickshanks> | okay, so that isn't how the HTML4 version works |
| 18:43 | <nickshanks> | zcorpan: seems like it would work in HTML5 with some simple changes for what we want |
| 18:43 | <nickshanks> | but that means the current HTML4 version would need to be a secondary document, one that HTML authors aren't going to come across easily |
| 18:43 | Philip` | isn't sure what the difference is |
| 18:44 | <nickshanks> | Philip`: ? difference with what |
| 18:45 | <Philip`> | Between the HTML4 version and HTML5 version |
| 18:46 | <nickshanks> | well the js linked above operated on <section staus=""> tags |
| 18:47 | <nickshanks> | it would be simpler to write a different javascript IMO |
| 18:47 | <nickshanks> | not that it matters too much at this point anyway |
| 18:47 | <Philip`> | Ah, no, that's the <section>s in http://www.whatwg.org/specs/web-apps/current-work/annotate-data.xml |
| 18:48 | <nickshanks> | ooh, thanks :) |
| 18:57 | <zcorpan> | the magic of hiding stuff that doesn't apply to authors could be done in the multipage script instead, i don't know which would be simpler to do |
| 18:57 | <Philip`> | Depends on whether you like JavaScript or Python, I guess |
| 18:58 | <Philip`> | I suppose JS has the problem that you wouldn't want authors to download 1.5MB of spec and then have their JS engine chug over it for a minute and then throw most of the document away |
| 18:59 | <zcorpan> | that's why it's multipage, no? :) |
| 18:59 | <zcorpan> | but indeed |
| 19:00 | <zcorpan> | if done with js, it could work with both the single page version and the multipage version |
| 19:00 | <Philip`> | Oh, I forgot about that one :-) |
| 19:00 | <zcorpan> | if done with python, it would only work with the multipage version, which is ok because people who would read the subset view would probably prefer multipage anyway |
| 19:01 | <Philip`> | The Python one could generate a stripped-down version of the single-page version easily |
| 19:01 | <zcorpan> | ok |
| 19:01 | <nickshanks> | just hope it doesn't strip away everything :) |
| 19:01 | <Philip`> | (just by having it load the original, do the stripping, then write the single-page output, then split it into sections and write all the sections) |
| 19:02 | <zcorpan> | right |
| 19:02 | <Philip`> | I suppose at least some sections would involve stripping everything away |
| 19:07 | <zcorpan> | we could perhaps just write css that hides stuff |
| 19:08 | <zcorpan> | #status+p+p, ...all other thigns that are to be hidden... { display:none; } |
| 19:08 | zcorpan | looks into whether that would work |
| 19:09 | <Philip`> | We really should use the 'irrelevant' attribute, but then it couldn't easily change relevance depending on the audience |
| 19:11 | <zcorpan> | i was thinking of just an alternate style sheet |
| 19:12 | <zcorpan> | you get the full spec by default, but can change to the subset view using the browser's style sheet switcher |
| 19:12 | <zcorpan> | or with a scripted link or #hash in the uri or whatever |
| 19:13 | <annevk> | Acid3 should test :target |
| 19:14 | <nickshanks> | what about :target needs an acid test? |
| 19:14 | <nickshanks> | seems to work fine for me |
| 19:15 | <Philip`> | Maybe HTML5 should allow <div audience="authors">...<p irrelevant="authors">...<p>...<p irrelevant="authors">...</div> |
| 19:15 | <zcorpan> | :target+p doesn't work correctly in safari |
| 19:15 | <Philip`> | then you could fake it in legacy browsers with CSs like [irrelevant] { display: none } [audience="authors"] [irrelevant="authors"] { display: inherit } |
| 19:15 | <Philip`> | *CSS |
| 19:15 | <zcorpan> | Philip`: let's not make it harder than it needs to be :) |
| 19:16 | <Philip`> | zcorpan: CSS is for presentation, but this is altering the semantics of the document so it's a guide for authors instead of a normative spec, hence the need for an HTML attribute rather than CSS :-) |
| 19:17 | <zcorpan> | Philip`: when there are implementations of irrelevant="" i might change my mind, but for now i'm trying to find the simplest solution possible |
| 19:17 | Philip` | likes making things harder than they need to be, as long as he doesn't actually have to do any work for them |
| 19:17 | <nickshanks> | alternativlyly, you caould say it is the "don't present me with too much info" viewing |
| 19:17 | <zcorpan> | it's not like authors will read the subset view with lynx or anything... and even if they did lynx doesn't support irrelevant="" |
| 19:18 | <Philip`> | Authors could submit patches to lynx |
| 19:18 | <zcorpan> | if selecting already present elements is good enough, it seems to me that just having an alternative stylesheet is the simplest |
| 19:19 | <zcorpan> | that stylesheet could be created by the status script |
| 19:19 | <zcorpan> | or inserted by the status script... if we want to maintain the stylesheet separately |
| 19:28 | <zcorpan> | this seems to work better than i expected |
| 19:39 | hsivonen | just got more convinced about the relative efficiency of the WHATWG working methods |
| 19:39 | <annevk> | heh, could have told you that beforehand |
| 19:41 | <hsivonen> | annevk: John Boyer's reply to you was most interesting |
| 19:41 | <om_phone> | hsivonen: I can't believe he said "we don't have to answer that" |
| 19:41 | <annevk> | hsivonen, to me or someone else? |
| 19:41 | <hsivonen> | annevk: to you, I think |
| 19:42 | <annevk> | hsivonen, to be honest, I missed his interesting reply I'm afraid |
| 19:42 | <annevk> | at least, I don't recall any |
| 19:42 | <hsivonen> | annevk: what othermaciej quoted above |
| 19:42 | <othermaciej> | I think that was to MatthewRaymond |
| 19:43 | <annevk> | didn't DanC say that? |
| 19:43 | <hsivonen> | oh |
| 19:43 | <annevk> | in reply to me? |
| 19:43 | <othermaciej> | I'm pretty sure John Boyer said that |
| 19:43 | <jdandrea> | <DanC> re "no answer necessary"... I'll have to elaborate in email. that's not a very good record of what I said. or meant. ??? |
| 19:43 | <annevk> | That they're not obliged to answer that question and that we're in this together or something... |
| 19:43 | <annevk> | That seems to confirm it was indeed the chair |
| 19:43 | <othermaciej> | well, I was a bit confused about who said what |
| 19:44 | <annevk> | Although othermaciej raised the question again in a different form and he didn't say it again... |
| 19:44 | <hsivonen> | I thought it was Boyer's voice |
| 19:44 | <hsivonen> | anyway, it bothers me that XForms Transitional is taken for granted |
| 19:44 | <annevk> | from the minutes: "DanC: good question to ask, no answer necessary" |
| 19:44 | <annevk> | to me it seemed like a reasonable question... |
| 19:45 | <annevk> | as it seems that the HTML WG generally agrees WF2 is a good idea |
| 19:45 | <othermaciej> | oh, per the minutes it says DanC, I assume he'll correct it if it wasn't him |
| 19:55 | <annevk> | it was him (per #html-wg) |
| 20:09 | <zcorpan> | perhaps the status markers would be easier to implement with a stylesheet too |
| 20:09 | <zcorpan> | it's already implemented though but we still need a way to maintain it and extend it with "implemented" markers etc |
| 20:10 | <zcorpan> | a stylesheet seems to be a lot simpler |
| 20:11 | <Philip`> | Does it have to work in IE7? |
| 20:12 | <zcorpan> | ie7 doesn't support generated content... so ms would have to implement that for ie8 :) |
| 20:12 | <hsivonen> | I wonder what browser the people who complain about the single-page spec size use |
| 20:13 | <Philip`> | Will the IE developers be reading the HTML5 spec in IE? :-) |
| 20:13 | <hsivonen> | WFM in Firefox and Opera |
| 20:13 | <zcorpan> | hsivonen: yeah. in ie7 it is a real pain. in firefox it freezes for a second when you do autoscrolling. in opera it works fine. |
| 20:14 | <zcorpan> | don't know about safari |
| 20:14 | <hsivonen> | works fine in Opera even a device with 64 MB of RAM (haven't tried in Minimo, yet) |
| 20:14 | <Philip`> | It seems to work alright for me in IE6 - it takes twenty seconds to load then has a JS error (missing XMLHttpRequest), but otherwise it seems perfectly fine |
| 20:34 | <zcorpan> | ponder, some things in the spec are only defined in terms of ua conformance requirements, if i were to hide all ua conformance requirements then authors wouldn't know how e.g. document.URL works |
| 20:34 | <annevk> | conformance for APIs is a red herring |
| 20:34 | <annevk> | I'm not entirely sure what "red herring" implies, but I think my usage of it here is correct :) |
| 20:35 | <zcorpan> | annevk: what i said was that authors want to know what the APIs do |
| 20:36 | <annevk> | fair enough |
| 20:36 | <othermaciej> | I don't think "red herring" applies here |
| 20:36 | <othermaciej> | "red herring" implies that something was brought up as a relevant point but is actually not applicable to the issue at hand |
| 20:36 | <othermaciej> | a meaningless distraction |
| 20:36 | <annevk> | hah, ignore me then! |
| 20:37 | <zcorpan> | so some UA conformance requirements would have to stay in the "author subset view", or would have to be rewritten as statements of facts for authors in that view |
| 20:37 | <othermaciej> | conformance requirements for API use are in general dubious, since no kind of automated verification is possible |
| 20:37 | <othermaciej> | however, other languages such as C do have such a concept, basically any program that is syntactically valid and does not rely on undefined behavior |
| 20:37 | <othermaciej> | I think many C programs implicitly rely on technically undefined behavior though |
| 20:38 | <zcorpan> | like encoding? (just guessing here) |
| 20:38 | <othermaciej> | the fact that char is exactly 8 bits |
| 20:38 | <othermaciej> | is one of the more common ones |
| 20:39 | <zcorpan> | ok |
| 20:39 | <othermaciej> | assuming that C strings are in ASCII encoding is another |
| 20:40 | <zcorpan> | before i asked my teacher in programming what encoding C used. "extended ascii" he said. |
| 20:41 | <zcorpan> | i said i didn't know what extended ascii meant -- is it windows-1252, iso-8859-1, utf-8, or what? he couldn't answer that |
| 20:41 | <zcorpan> | google didn't help me either |
| 20:42 | <zcorpan> | it seems to me that it depends on the compiler, but i'm not sure |
| 20:43 | <hsivonen> | hrm. Opera doesn't do SVG arrowheads |
| 20:43 | <othermaciej> | it depends on the compiler and on the C library |
| 20:43 | <hsivonen> | Prince doesn't either. grr |
| 20:43 | <hsivonen> | Firefox and WebKit support them |
| 20:43 | <hsivonen> | yay for interop |
| 20:44 | <zcorpan> | othermaciej: ok |
| 20:55 | <Philip`> | zcorpan: Do you mean the encoding of the source code files, or of the strings passed to/from the C standard library? |
| 20:55 | <zcorpan> | the source code files |
| 20:56 | <Philip`> | C99 says "Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary." |
| 20:56 | <Philip`> | so that's not undefined behaviour |
| 20:57 | <zcorpan> | just implementation-defined? |
| 20:58 | <othermaciej> | implementation-defined behavior is undefined, if you assume it is being done in some specific way |
| 20:58 | <othermaciej> | for instance, assuming your physical source is UTF-16 and is translated to a source character set of UTF-8 would be wrong |
| 20:58 | <Philip`> | The source character set is letters, digits, and 29 graphic characters, and some whitespace |
| 20:58 | <Philip`> | "If any other characters are encountered in a source file (except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token), the behavior is undefined." |
| 20:59 | <zcorpan> | ah |
| 20:59 | <zcorpan> | ok |
| 20:59 | <zcorpan> | our teacher did printf("hallå där"); all the time |
| 20:59 | <Philip`> | but inside a string literal, it sounds like it allows any character (i.e. single byte) |
| 21:00 | <Philip`> | othermaciej: The difference is that implementation-defined behaviour is documented by the implementation, whereas undefined behaviour isn't |
| 21:01 | <Philip`> | (in their terminology) |
| 21:01 | <Philip`> | but it's as good as undefined if you can't find the documentation for it :-) |
| 21:03 | <annevk> | zcorpan, so to get CSS fixed some browsers need to change behavior... |
| 21:03 | <Philip`> | Oh, I'm wrong about it being a single byte - only the source character set must be, but you can have other multibyte characters |
| 21:03 | <Philip`> | (as far as I can see) |
| 21:04 | <zcorpan> | annevk: what are you referring to? |
| 21:04 | <annevk> | xhtml body |
| 21:04 | <zcorpan> | ah |
| 21:04 | <zcorpan> | yes |
| 21:04 | <Philip`> | but it all seems like implementation-defined behaviour - the only requirement is that '0'..'9' are sequential character codes, which I guess is true even in EBCDIC |
| 21:05 | <Philip`> | (In the code I've worked on, we've avoided the problems by rewriting German names to have nice ASCII "ae" instead, though that was problems with editors and SVN rather than with the compiler...) |
| 21:06 | <zcorpan> | annevk: so it's time to file bugs about this, eh? |
| 21:06 | <annevk> | think so |
| 21:06 | zcorpan | goes ahead and does so |
| 21:12 | <annevk> | whoa, w3.org is slow |
| 21:12 | <zcorpan> | indeed |
| 21:13 | <annevk> | guess the telcon took all their resources :p |
| 21:26 | <annevk> | although I don't entirely agree with the CSS WG (which I'm in...) |
| 21:27 | <annevk> | this is not about what implementations do, but about what's better for XHTML |
| 21:33 | <zcorpan> | is the css21 spec in cvs? where? |
| 21:34 | <annevk> | Member only |
| 21:35 | <zcorpan> | ok |
| 21:35 | <annevk> | not really :p |
| 21:36 | <zcorpan> | didn't imply that it was ok :) |
| 21:36 | <zcorpan> | meant ok as in "so now i know" |
| 21:37 | <zcorpan> | ...and don't need to search further |
| 21:39 | <annevk> | i know (hence the smiley) |
| 21:44 | zcorpan | considers creating equivalent html and xhtml test cases that are the same byte by byte |
| 21:45 | <zcorpan> | either that or i should run a script that converts html tests to equivalent xhtml |
| 21:45 | <annevk> | that's doable now |
| 21:46 | <Philip`> | How do you test that the converter is correct? |
| 21:46 | <annevk> | not talking about converting |
| 21:46 | <annevk> | talking about byte identical tests with a different MIME type |
| 21:46 | <annevk> | where both are conforming |
| 21:47 | <zcorpan> | Philip`: with the parsing test suite? |
| 21:47 | <zcorpan> | annevk: [22:50] <zcorpan> either that or i should run a script that converts html tests to equivalent xhtml |
| 21:47 | annevk | replies to Philip` |
| 21:47 | <Philip`> | Ah, are xmlns and xml:lang and stuff now conforming HTML5? |
| 21:47 | <annevk> | replied* damn it |
| 21:47 | <annevk> | Philip`, xmlns is |
| 21:48 | <annevk> | the cool thing about that is not byte identical files though |
| 21:49 | <annevk> | it's that you can write <html xmlns=http://www.w3.org/1999/xhtml>; and do a happy dance |
| 21:49 | <zcorpan> | lol |
| 21:53 | <Philip`> | annevk: Aha, okay. (I was remembering what I'd done for HTML->XHTML conversion, and forgot the (xml:)lang is optional) |
| 21:54 | <annevk> | I think we should get rid of xml:lang and just make it lang throughout |
| 21:54 | <annevk> | same reasons as for not adopting xml:id |
| 21:55 | <annevk> | actually, we still have to define that xml:lang takes precedence, when specified |
| 21:55 | <zcorpan> | annevk: isn't that defined already? |
| 21:56 | <zcorpan> | or nm |
| 21:56 | <annevk> | (it was in reply to me suggesting getting rid of it altogether) |
| 21:57 | <zcorpan> | (figured) |
| 21:59 | <Philip`> | The spec says the xml:lang attribute takes precedence over the lang attribute, but is that talking about the "lang" attribute in the "xml" namespace, as distinct from the "xml:lang" attribute in the default namespace (like what an HTML5 parser would produce)? |
| 21:59 | <hsivonen> | offtopic: do I understand correctly that <svg height="50%"> in a compound document refers to the height of the containing block if the containing block has a non-auto height and to the width of the containing block if the height of the containing block is auto? |
| 22:00 | <annevk> | Philip`, oh, lang in xml: |
| 22:00 | <annevk> | hsivonen, that sounds wrong |
| 22:00 | <zcorpan> | Philip`: see #terminology |
| 22:00 | <annevk> | hsivonen, unless it has an aspect ratio of 1:1 |
| 22:00 | <annevk> | hsivonen, or something |
| 22:01 | <hsivonen> | annevk: ok. what's the right answer? what do height percentages on outer <svg> refer to? |
| 22:01 | <Philip`> | annevk: So that precedence rule can only apply to document deserialised from XHTML5 and not HTML5? (I think that makes sense now) |
| 22:02 | <annevk> | hsivonen, I'm not an expert on this, but I believe it becomes a CSS height of 50%. |
| 22:02 | <zcorpan> | Philip`: if you don't do scripting then yes |
| 22:02 | <annevk> | hsivonen, http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width and http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height would then clarify what happens |
| 22:03 | <annevk> | hsivonen, the problem is though that I believe the CSS WG agreed to change those sections (again!) so it's likely something different in a couple of weeks |
| 22:04 | <hsivonen> | annevk: WebKit and Gecko seem to follow my hypothesis |
| 22:04 | <hsivonen> | annevk: can't figure out what Opera does |
| 22:04 | <annevk> | Gecko has the wrong implementation of SVG height and width |
| 22:04 | <annevk> | dunno about WebKit |
| 22:05 | <annevk> | Opera had something close to CSS 2.1 (but now that changed!) in some build (parts might be in Opera 9) |
| 22:05 | <hsivonen> | annevk: so what's the intrinsic ratio for SVG? the ratio of viewBox? |
| 22:05 | <hsivonen> | annevk: I've got 9.20 |
| 22:05 | <annevk> | I think so |
| 22:06 | <hsivonen> | considering that I'm making a document that is supposed to last years unmodified, I don't like this |
| 22:06 | <annevk> | SVG is either really vague about all this or it's just me |
| 22:06 | <annevk> | which is certainly possible |
| 22:06 | <annevk> | Besides 42, I suppose the answer is PNG |
| 22:07 | <hsivonen> | basically, I wan't to say "give me 100% and the height that is right for the viewBox aspect ratio" |
| 22:07 | <hsivonen> | s/100%/100% width/ |
| 22:08 | <hsivonen> | annevk: one possibility is that height can compute to auto, but height='auto' is an error and falls back to height='100%' |
| 22:08 | annevk | wonders how CSS 2.1 can go to LC while changing intrinsic widths |
| 22:08 | <annevk> | and heights |
| 22:08 | <annevk> | a block with percentage height within one with height auto becomes 0 |
| 22:08 | <hsivonen> | and it certainly doesn't help that em-sized SVG in horked in Gecko |
| 22:12 | <hsivonen> | rough interop with the moron method achieved between WebKit, Firefox trunk and Prince |
| 22:12 | <hsivonen> | unwanted results in Opera |
| 22:13 | <hsivonen> | I have to say that SVG/CSS cooperation has a serious counterintuitiveness or downright brokenness in this very reasonable use case |
| 22:13 | <annevk> | post it to www-style |
| 22:13 | <annevk> | maybe www-svg |
| 22:14 | <annevk> | I would like to be more of assistence, but people just tell me how they think it should work, without actually saying where that's defined |
| 22:14 | <annevk> | (for instance, the SVG WG said that percentage widths / heights on svg:svg elements don't contribute to the intrinsic width / height mechanism in CSS) |
| 22:15 | <annevk> | (where implementors and testcase writers assumed it they would) |
| 22:15 | <hsivonen> | annevk: current attempt: http://hsivonen.iki.fi/thesis/html5-conformance-checker.xhtml#back-end |
| 22:15 | <hsivonen> | bed time |
| 22:17 | <hsivonen> | annevk: thanks. I will have to investigate more |
| 22:18 | <hsivonen> | annevk: perhaps use the Distler em hack and use ems that equal 100% under my particular Prince conditions |
| 22:41 | <zcorpan> | is http://simon.html5.org/test/css/magic-body/003.htm too evil? |
| 22:42 | <Hixie> | too evil for what? |
| 22:42 | <Hixie> | it's blank on ff2 |
| 22:43 | <Hixie> | seems quite reasonable to me |
| 22:43 | <zcorpan> | i mean, too much an edge case for being relevant for web content |
| 22:43 | <zcorpan> | however the situation is more likely in xml so |
| 22:44 | <Hixie> | it's not something that will be run into frequently, but it should work |
| 22:44 | <Hixie> | it's not a P1, but it should work |
| 22:44 | <zcorpan> | ok |
| 22:46 | <nickshanks> | i get a white page with no text in safari (title works though) |
| 22:46 | <Hixie> | do you get a js error in safari? |
| 22:47 | <Hixie> | (if anything fails at replaceChild() you'll get a blank page) |
| 22:47 | <zcorpan> | blank page in firefox 2 is weird. the dom looks ok and it works in firefox 3 (but it still fails the test) |
| 22:47 | <Hixie> | i wonder why it doesn't render anything in ff2 |
| 22:47 | <Hixie> | weird |
| 22:47 | <Hixie> | oh it works on trunk? ok |
| 22:48 | <Hixie> | then who cares about ff2 :-) |
| 22:48 | <zcorpan> | indeed :) |
| 22:48 | <Hixie> | k |
| 22:48 | <Hixie> | well |
| 22:48 | <Hixie> | i told the htmlwg that r1000 was the version we were putting forward |
| 22:48 | <Hixie> | i guess i'd better get cracking on commiting changes |
| 22:49 | <Hixie> | since we're just under r700 at the moment |
| 22:50 | <zcorpan> | if you want me to bug you about typos then shout ;) |
| 22:50 | <Hixie> | nah |
| 22:50 | <Hixie> | still too early for typos |
| 22:50 | <zcorpan> | </kidding> |
| 22:50 | <Hixie> | i think i'll just start responding to feedback |
| 22:50 | <Hixie> | oh there'll come a time where typos will be critical :-) |
| 22:50 | <Hixie> | that's when the spec is done :-P |
| 22:50 | <zcorpan> | yeah |
| 22:57 | <jgraham> | http://wordsandpictures.dyndns.org/html5/html5view.html (this is very much unpolished) |
| 22:57 | <jgraham> | (and probably very buggy) |
| 23:00 | <zcorpan> | no type=url? |
| 23:01 | <jgraham> | zcorpan: Did I not say unpolished ;) |
| 23:01 | <zcorpan> | you did :) |
| 23:01 | <Philip`> | Hmm, I guess google.com is a bad page to try it on, since it has an extra link (Scholar) in the top one... |
| 23:02 | <Philip`> | yahoo.com is bad too since they ask html5lib to upgrade to a newer browser |
| 23:03 | <zcorpan> | got an error for http://simon.html5.org/sandbox/html/w3c-home-in-html5 |
| 23:04 | <jgraham> | So I guess UA spoofing would help... |
| 23:04 | <Philip`> | And microsoft.com seems to generate no response from the lower window :-( |
| 23:05 | <jgraham> | zcorpan: Known bug in html5lib. Hixie hasn't specced what to do with <header> and other new tags yet... |
| 23:05 | <zcorpan> | jgraham: aren't they covered by "anything else" then? |
| 23:05 | <Philip`> | msdn.microsoft.com causes "<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode character u'\u222b' in position 217: ordinal not in range(128) "%(value, node.attributes[key]) UnicodeEncodeError: 'ascii' codec can't encode character u'\u222b' in position 217: ordinal not in range(128) -->" |
| 23:05 | <zcorpan> | (for now, that is) |
| 23:05 | <bewest> | jgraham: is this just two iframes? |
| 23:06 | <Philip`> | Oops, the latter half of the error is caused by printing the traceback unescaped when it contains a line "print "<!-- link %s changed to %s-->"%(value, node.attributes[key])" |
| 23:07 | <jgraham> | bewest: Yeah two iframes. However the html5lib frame has to build up the DOM using js to avoid browser parsing errors |
| 23:07 | <bewest> | ah |
| 23:08 | <zcorpan> | jgraham: or use xhtml5? although i guess that won't work in ie :) |
| 23:08 | <bewest> | so it renders a tree constructed using html5 rules in the browser? |
| 23:08 | <jgraham> | s/errors/oddities/ |
| 23:08 | <jgraham> | bewest: Yeah, that's the idea |
| 23:10 | <jgraham> | Hmm. Clearly I need to work on I18n |
| 23:10 | <Philip`> | w3.org looks different in the two - is this a quirks vs standards issue? |
| 23:10 | <Philip`> | (The spacing around the logo and between some lines is different) |
| 23:10 | <bewest> | ah... it makes sense when I hit the url from the command line |
| 23:11 | <bewest> | that loadom=1 is insane |
| 23:12 | <bewest> | oh loaddom=1 |
| 23:13 | <jgraham> | Philip`: possibly. Firefox has helpfully taken the rendering mode out of the page info dialog... |
| 23:13 | <bewest> | jgraham: why show the rendered version? from the initial description I thought it would show a comparative visualization of the two trees as opposed to a rendering of them |
| 23:13 | <zcorpan> | it is |
| 23:13 | <bewest> | hmmmm |
| 23:15 | <zcorpan> | jgraham: the second iframe should probably either always use <!doctype html> or use the same prolog as the input document |
| 23:15 | <jgraham> | bewest: http://wordsandpictures.dyndns.org/html5/parsetree.html almost does what you want (it shows the html5 tree which you can compare with the live DOM viewer) |
| 23:15 | <Philip`> | jgraham: Oh, I hadn't noticed they'd changed that, but it does like quite <sarcasm>helpful</sarcasm> now |
| 23:17 | <jgraham> | zcorpan: It should keep the same doctype (but obviously doesn't) |
| 23:18 | <bewest> | jgraham: nifty |
| 23:19 | <Philip`> | Looks like it adds <!DOCTYPE HTML> for HTML 4.01 pages, but not for XHTML pages (or at least ones with <?xml ...?>) |
| 23:20 | <Philip`> | (Doctype sniffing sounds like fun - let's do more of it!) |
| 23:22 | zcorpan | wonders if he should have a third set of tests -- html in quirks mode |
| 23:23 | <zcorpan> | and almost standards mode? man, all these modes makes creating test cases trivial indeed |
| 23:23 | <zcorpan> | let's introduce more rendering modes while we're at it |
| 23:25 | zcorpan | will try to get the "almost" and "full" modes merged, i.e. get the "almost" mode specced in css21 |
| 23:25 | <zcorpan> | wish me luck |
| 23:25 | <Hixie> | we will shortly be getting more rendering modes! |
| 23:25 | <zcorpan> | yay! :( |
| 23:27 | <othermaciej> | ah, rendering modes |
| 23:28 | <zcorpan> | i wish there was only quirks mode |
| 23:28 | <Hixie> | i wish there was only one mode and it matched the specs |
| 23:29 | <zcorpan> | me too, which effectively means the specs should have adopted to quirks mode a few years back |
| 23:32 | <zcorpan> | i'll aim to merge almost and full, and reduce the number of html vs xhtml differences to a minimum, and then spec quirks... i have no idea what to do with whatever ms comes up with |
| 23:32 | <zcorpan> | hopefully other vendors won't have to implement new modes |
| 23:39 | <Hixie> | hopefully |
| 23:40 | <zcorpan> | and hopefully the web will use new features in quirks mode and "html4-mode" so ms have to implement them there as well :) |
| 23:42 | <zcorpan> | not that i think it will affect them, i mean most authors have to make it work in current IEs somehow (so long as they are majority vendor anyway) |
| 23:43 | <othermaciej> | Chris Wilson is definitely giving other vendors a lot more motive to reduce IE market share |
| 23:43 | <Hixie> | in a "win or die" kind of way, yeah |
| 23:45 | <Philip`> | zcorpan: People using SVG or canvas today don't seem to worry much about making it work in current IEs |
| 23:45 | Hixie | comes across an old thread where someone is asking for something, an xforms person replies with "xforms can do that!", and the original commentor dismisses that as being irrelevant to web browsers |
| 23:45 | <Philip`> | though there aren't exactly many of those people |
| 23:45 | <Hixie> | not one of the usual suspects, either |
| 23:46 | <zcorpan> | Philip`: it's possible to make both work in ie using script |
| 23:46 | <zcorpan> | i.e., "work" |
| 23:48 | <zcorpan> | to address the xslt use-case, we should make the html4 strict doctype conforming :) |
| 23:49 | <zcorpan> | (and perhaps xhtml1 strict too) |
| 23:49 | <Hixie> | wow, we basically hit almost everything on this list: http://www.joelonsoftware.com/oldnews/pages/June2004.html |
| 23:52 | jdandrea | reads the 17 June 2004 entry - ha-HA! Nice. |
| 23:53 | <othermaciej> | nice :-) |
| 23:53 | <othermaciej> | can datagrid be used as a tree/outline view? |
| 23:53 | <Hixie> | yeah |
| 23:54 | <othermaciej> | compressed JS can already be done via http 1.1 |
| 23:54 | <othermaciej> | (trying to find what is missing) |
| 23:54 | <Hixie> | modal dialogs are missing |
| 23:54 | <Hixie> | but that's intentional |
| 23:54 | <bewest> | not sure why he wants... yeah exactly |
| 23:54 | <jdandrea> | (See also the 25 June 2004 entry with quotes from Brendan Eich and hixie!) |
| 23:54 | <Hixie> | contentEditable isn't perfect, but that's hard to do, i don't know what else to do about it |
| 23:54 | <bewest> | why would we want a modal windowing model on the web? |
| 23:56 | <Philip`> | (If datagrid is for trees, could it do something like the 'expand' links in http://canvex.lazyilluminati.com/tests/tests/, maybe with some scripting/styling? Er, I should probably read it myself some time to see...) |
| 23:57 | <Hixie> | i don't think it trivially does that, no |
| 23:57 | <Hixie> | it only supports showing all or nothing at a particular node and level |
