| 00:13 | <annevk> | fixed |
| 00:13 | <annevk> | for a while it installed lxml 2.3 beta 1 which did not work |
| 00:13 | <annevk> | so I had to figure out you had to do this instead |
| 00:13 | <annevk> | easy_install lxml==2.2.2 |
| 00:13 | <Hixie> | thanks dude |
| 00:13 | <annevk> | as easy_install lxml 2.2.2 does nothing o_O |
| 00:57 | <Hixie> | hey can someone who knows how the webappswg handles test suites reply to drew's e-mail about where he should put his web workers tests? |
| 00:57 | <Hixie> | i haven't been following how we do tests since, well, i have no time to work on tests and wrote the spec anyway so shouldn't really write the tests for it |
| 00:58 | <othermaciej> | I wish I knew how the web apps wg handles tests |
| 01:00 | gsnedders | realizes with his travel plans he's going to have fun renewing his passport… yay :\ |
| 01:01 | <wilhelm> | Moving back to Sweden or just visiting? :P |
| 01:30 | <MikeSmith> | I think the webapps WG as a whole doesn't, and that within the group, it depends on which spec |
| 01:30 | <MikeSmith> | but I think we need to change that |
| 01:31 | <MikeSmith> | not just for webapps, but across groups that are working on Web platform / browser-technology specs |
| 01:32 | <MikeSmith> | we all keep talking about this, but I think we need to actually make it happen this year |
| 01:32 | <MikeSmith> | it being, setting up a common mechanism for managing and running test suites |
| 01:34 | <MikeSmith> | anyway, the answer for now is that he is encouraged to check in the tests here: |
| 01:34 | <MikeSmith> | http://test.w3.org/html/tests/submission/ |
| 01:35 | <MikeSmith> | oh |
| 01:35 | <MikeSmith> | hmm, yeah, that's under /html |
| 01:36 | <MikeSmith> | I'll set up a corresponding one under http://test.w3.org/webapps/tests/ |
| 01:38 | <MikeSmith> | hmm, but I see anne set up a tests dir under http://dvcs.w3.org/hg/webapps/ already too |
| 01:46 | <MikeSmith> | http://test.w3.org/webapps/tests/submission/ |
| 01:47 | <MikeSmith> | http://dvcs.w3.org/hg/webapps/file/tip/tests/submission/ |
| 01:51 | <wilhelm> | MikeSmith: For running tests, the W3C really should standardize on a handful of sane test runners appropriate for each test type. We've imported a large number of tests from others, modifying 19 different test frameworks to talk to our central test systems. |
| 01:51 | <MikeSmith> | wilhelm: agreed |
| 01:51 | <MikeSmith> | pretty much everybody agrees |
| 01:51 | <MikeSmith> | we just need to finally make it happen |
| 01:52 | <MikeSmith> | I expect to be spending time myself this year on helping to do that |
| 01:52 | <wilhelm> | Put a tester from each browser vendor in a room and don't let them out until they agree on something that works for all. (c: |
| 01:53 | <MikeSmith> | yeah |
| 01:53 | <MikeSmith> | this is something that could genuinely benefit from f2f time |
| 01:53 | <MikeSmith> | so start planning for a trip to SF Bay area in the next few months, I guess |
| 01:54 | <wilhelm> | The different JS test frameworks aren't _that_ different from each other, though. I'm more concerned about testing stuff that ordinarly would require some soft of user interaction. At Opera, we use the Watir API for such tests. We have about 500-600 tests of HTML form interaction, for example. That would be good to share. |
| 01:54 | <wilhelm> | MikeSmith: Send me an invitation I can show to my boss, and I'd be happy to come over. (c: |
| 01:54 | <MikeSmith> | will do |
| 01:54 | <MikeSmith> | and understood, about the user interaction tests |
| 01:55 | <Hixie> | hey if all you guys need is a room for a day, i can get you one, let me know |
| 01:55 | <wilhelm> | Here's the framework we use for that: http://operawatir.org/ |
| 01:55 | <Hixie> | (or TabAtkins can, either way) |
| 01:55 | <MikeSmith> | Hixie: that would be great |
| 01:55 | <MikeSmith> | ok |
| 01:55 | <wilhelm> | Our implementation of WebDriver will also be made public Real Soon Now. Both those APIs are moderately well supported by all browsers now. |
| 01:56 | <MikeSmith> | I will talk to plh and start getting a f2f plan together |
| 01:56 | <Hixie> | give us plenty of notice, though, the meeting rooms are notoriously hard to book cos we're growing so fast :-) |
| 01:56 | <Hixie> | cool |
| 01:56 | <TabAtkins> | Indeed, getting a room for a day is possible with sufficient forwarning. |
| 01:57 | <TabAtkins> | Hixie: Crittenden is usually open, given a week or so of notice. |
| 01:57 | <Hixie> | well yeah, but you don't want to have to meet it crittenden! |
| 01:57 | <TabAtkins> | What? Why? It's just down the road. |
| 01:57 | <wilhelm> | … |
| 01:57 | <Hixie> | the dinosaur is outside b43! |
| 01:57 | <Hixie> | it's like a mile away |
| 01:57 | <wilhelm> | Is it full of critters? |
| 01:57 | <TabAtkins> | Sure, so you start there. And then you take a refreshing walk to Crittenden. |
| 01:57 | <TabAtkins> | Or, even better, CONFERENCE BIKE. |
| 01:58 | <Hixie> | hah, i'd love to see the look on a working group's face as we inform them of how they're getting to their meeting place :-P |
| 01:59 | <MikeSmith> | TabAtkins: we can plan well ahead to do it when we can be sure we get as many of the right people attending as we can |
| 01:59 | <MikeSmith> | and when they have time |
| 02:00 | <MikeSmith> | e.g., maybe we would not want to do this until after FF4 ships |
| 02:00 | <MikeSmith> | because maybe they are not going to have a lot of time freed up until then |
| 02:00 | <Hixie> | you don't want too many people, more than two or so per vendor and it'll quickly get out of hand |
| 02:00 | <TabAtkins> | kk |
| 02:00 | <TabAtkins> | Yes. |
| 02:00 | <TabAtkins> | Never put more than a dozen people in a room together and expect to get anything done. |
| 02:01 | <MikeSmith> | yeah, true |
| 02:01 | <MikeSmith> | we can make that one of the ground rules I guess |
| 02:01 | <MikeSmith> | 2 reps per vendor at the actual f2f |
| 02:02 | <MikeSmith> | though it would also be a good chance to have some actual social time together around it |
| 02:02 | <Hixie> | opera can have more reps, rotating them in during the day, so that i can see more of them :-P |
| 02:02 | <MikeSmith> | yeah, I was going to say, it would be hard to limit the number of Opera people |
| 02:03 | <wilhelm> | :P |
| 02:03 | <Hixie> | anyway the real reason i need notice is so that i can book two rooms, one for the meeting for y'all, and one for us to play some board games |
| 02:03 | <MikeSmith> | heh |
| 02:04 | <Hixie> | it's hard to find good board game rooms that are free and near good meeting rooms :-) |
| 02:04 | <TabAtkins> | I'd think the 4-person meeting rooms are good for that? |
| 02:04 | <Hixie> | most meeting rooms have desks with cables and stuff for laptops which board games relly don't like |
| 02:04 | <Hixie> | TabAtkins: the round tables have cable holes in the middle |
| 02:05 | <TabAtkins> | ah, yeah |
| 02:05 | <Hixie> | you really want actual desks you can push together |
| 02:06 | <wilhelm> | We could combine the two. Whoever wins 1856 gets to decide which test frameworks to use. |
| 02:07 | <Hixie> | lol |
| 02:07 | <Hixie> | i just want to play, i don't care about the test framework :-) |
| 02:11 | <MikeSmith> | sounds like you need some optimized gaming rooms |
| 02:14 | <MikeSmith> | hmm, microsyntax for valid e-mail address changing… |
| 02:15 | <MikeSmith> | I think the v.nu checker for e-mail addresses was not up to date with spec anyway |
| 02:16 | <Hixie> | not a high priority change anyway |
| 02:16 | <Hixie> | i was tempted to reject it in fact |
| 02:27 | <MikeSmith> | in other news, we do have support for checking dropzone now |
| 02:28 | <MikeSmith> | and the way it's implemented is a good example of tradeoffs between trying to have something useful in the base relaxng schema, along with additional (Java) code for checking other constraints |
| 02:29 | <Hixie> | cool |
| 02:33 | <MikeSmith> | in this case, the schema handles checking whether it the individual keywords are valid -- exactly one of copy, move, link and then any number of f:.* and/or s.* |
| 02:33 | <MikeSmith> | and the Java code handles checking whether there are any duplicates for any of the f: or s: keywords |
| 02:33 | <MikeSmith> | but |
| 02:33 | <Hixie> | fancy schema |
| 02:34 | <MikeSmith> | it could be implemented by adding a specific "datazone" datatype to the v.nu HTML datatype library, and putting all the checking in that |
| 02:34 | <MikeSmith> | the advantage of that would be better error reporting |
| 02:35 | <MikeSmith> | because then we get fine-grained control of the text of the error messages |
| 02:36 | <MikeSmith> | s/datazone/dropzone/ |
| 02:36 | <MikeSmith> | anyway, whereas with putting checks in the schema, we get more generic error messages that are less helpful to users in, e.g., pinpointing which keyword in the dropzone value is the offending one |
| 02:37 | <MikeSmith> | I guess there has been a progression in v.nu away from doing checks in the schema just because they can be |
| 02:38 | <MikeSmith> | and instead moving them into the Java code where we have more control and can emit better error messages |
| 02:38 | <MikeSmith> | I think for users of the different parts, it will end up as sort of a case of progressive enhancement |
| 02:39 | <MikeSmith> | or graceful degradation |
| 02:40 | <MikeSmith> | in that, if somebody wants to use the schema by itself, without the datatype library -- e.g., for use in a context-sensitive editor -- then they can't expect us to optimize the schema for that use case |
| 02:41 | <MikeSmith> | in fact, we and they are really better off if somebody produces a different schema that is optimized for that use case |
| 02:41 | <MikeSmith> | which is what we will have eventually, I'm sure |
| 04:37 | zcorpan | shamelessly steals some styles from developers.whatwg.org for http://simon.html5.org/html5-elements |
| 04:42 | <benschwarz_> | zcorpan: what do you need? :) |
| 04:44 | <zcorpan> | benschwarz_: dunno, i just copied some style rules. does it look ok? |
| 04:44 | <benschwarz_> | the headers look a bit over baring |
| 04:45 | <benschwarz_> | but nice to have it themed similarily |
| 04:45 | <benschwarz_> | I saw some hits from your site yesterday ( I added stats overnight ) |
| 04:45 | <zcorpan> | should i use the h4 style instead? |
| 04:47 | <benschwarz_> | zcorpan: leave it I think |
| 04:47 | <benschwarz_> | the elements look big |
| 04:47 | <benschwarz_> | you know what would rule? a find as you type search |
| 04:47 | <benschwarz_> | I'm going to do one for the specs myself |
| 04:47 | <benschwarz_> | when I get to it |
| 04:48 | <zcorpan> | isn't find as you type a browser feature? |
| 04:48 | <zcorpan> | benschwarz_: i think your <code>s look too small :P |
| 04:49 | <artenix> | Hi |
| 04:49 | <benschwarz_> | zcorpan: they are too small. the line widths are hard though |
| 04:49 | <benschwarz_> | I think I'm going to re-address it when i get to the .example styles |
| 04:50 | <artenix> | Reading about droping HTML5 ñame over HTML. Strong feelings on the web about it. |
| 04:51 | <zcorpan> | benschwarz_: you think i should change the line-spacing? |
| 04:53 | <artenix> | I don't care the name. I just want a standard way to detect the new capabilities on HTML. Will be there one? |
| 04:53 | <zcorpan> | artenix: http://diveintohtml5.org/detect.html |
| 04:55 | <artenix> | zcorpan tnx. So, use Modernizr lib uh? |
| 04:56 | <zcorpan> | yeah |
| 05:00 | <artenix> | Because now HTML is a living spec, I think the smartest thing is providing a well-designed and standard capability detection method. The soup http://diveintohtml5.org/detect.html will be a nightmare to use as HTML evolves |
| 05:02 | <benschwarz_> | Those with strong opinions about it weren't there when the canvas was empty. |
| 05:02 | <artenix> | Don't get me wrong, I am more than happy with WHATWG. I just want to see fixed the incompatability problems on HTML once and for all |
| 05:02 | <zcorpan> | artenix: what's wrong with the current detection mechanisms? |
| 05:03 | <artenix> | I don't enjoy using CSS hacks :) |
| 05:03 | <zcorpan> | you don't need css hacks to detect html5 features |
| 05:05 | <zcorpan> | artenix: fixing incompatibility problems is a large part of what whatwg is doing |
| 05:06 | <artenix> | zcorpan "call a method and see the return value" , "Set a property to a certain value, then check if the property has retained its value." C'mon! Is the best we can do? |
| 05:07 | <artenix> | "Use a JS lib somebody maintains... and hope she will be maintaining it in the years to come" |
| 05:08 | <zcorpan> | artenix: it's the most reliable we can do, yeah. http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0231.html |
| 05:08 | <artenix> | No sir, IMHO HTML needs a *standard* way to detect capabilities. |
| 05:09 | <artenix> | zcorpan lemme |
| 05:09 | <artenix> | zcorpan lemme read the lastima |
| 05:09 | <artenix> | s/ima// |
| 05:12 | <zcorpan> | artenix: there is a standard way to detect capabilities. you just look at what the feature you want to test actually is, and then see if it's there or not. e.g. for web sockets, it's a constructor called "WebSocket" exposed on window, so the detection is if ('WebSocket' in window) |
| 05:15 | <artenix> | Zcorpan and for <video> is different. |
| 05:16 | <zcorpan> | artenix: something like hasFeature has great problems with dividing up features you'd want to detect, not considering implementation bugs, and has a history of being completely unreliable and hence useless for its intended purpose |
| 05:16 | <artenix> | "Having something like DOM's hasFeature detect for larger sets of features doesn't work on the Web." I think more on testing SMALL set of features (or just 1) |
| 05:17 | <zcorpan> | what's "a small set of features" or "just one feature"? |
| 05:18 | <artenix> | I meant, hasFeature should test 1 small tiny specific on behaivor and semantic feature. |
| 05:19 | <artenix> | That way, $IMPORTANT_SITE could test for the fragores it really needs |
| 05:20 | <zcorpan> | problem with that is that it's a major undertaking to divide all the web platform's features into hasFeature strings and maintaining them and implementing them, which takes time away from implementing new features and fixing bugs in existing features |
| 05:20 | <zcorpan> | and i'm not convinced that it would STILL be reliable to actually be useful |
| 05:20 | <artenix> | s/fragores/features/ iPhone autocomplete needs debugging :) |
| 05:21 | <zcorpan> | the feature detection Modernizr uses comes for free when a browser implements the feature, which is good in two ways: it's reliable, and it doesn't cost anything |
| 05:24 | <artenix> | Look. I speak as a Web developer here. I need a reliable way to use the new exciting tags and technolgy associated with HTML(5) , while providing the simplest experience for users using older browsers. |
| 05:25 | <artenix> | Is WHATWG addresing that? |
| 05:26 | <zcorpan> | artenix: yeah. it's just that the feature detection method isn't as clean as you'd like |
| 05:28 | <zcorpan> | artenix: if we've tried to make the detection method clean and reliable, then that would take away time for bugfixing and new features |
| 05:29 | <zcorpan> | artenix: since there already is a reliable way to detect features, we'd rather spend time on fixing bugs and implementing new features |
| 05:30 | <artenix> | Ok. I can live with a "dirty" detection methods. But only if the browsers implementators agree on which dirtiness to use. I don't want to have to use one method for IE, another for FF, other for Opera, Safari, etc etc |
| 05:31 | <zcorpan> | deal :) |
| 05:31 | <artenix> | :-) |
| 05:33 | <artenix> | BTW who are you? ^_^ |
| 05:33 | <zcorpan> | Simon Pieters |
| 05:34 | <zcorpan> | you? |
| 05:35 | <artenix> | Nice to meet you. Arturo Tena, one of the many web developers out there. |
| 05:36 | <artenix> | Im exciting on having HTML moving forward after all this years |
| 05:37 | <artenix> | s/ing/ed/ My English is not so good |
| 05:38 | <benschwarz_> | artenix: have you seen the developers edition that is being worked on? |
| 05:38 | <benschwarz_> | its a start, anyway |
| 05:39 | <[tm]> | Mark Pilgrim's book is a great place to look too |
| 05:40 | <artenix> | ben hm not sure I grab the most recent stuff I found |
| 05:40 | <[tm]> | goes into detail bout this very stuff |
| 05:40 | <Hixie> | hey didn't the chairs make a couple of decisions this year already? i can't find it |
| 05:40 | <MikeSmith> | artenix: http://diveintohtml5.org/ |
| 05:40 | <artenix> | [Tm] oh tnx I will buy it |
| 05:40 | <MikeSmith> | Hixie: yeah, they did |
| 05:40 | <MikeSmith> | artenix: it's free |
| 05:40 | <MikeSmith> | online |
| 05:40 | <Hixie> | do you have a url to the decisions by any chance? |
| 05:41 | <Hixie> | i just went through the whole month of archives without success |
| 05:41 | <MikeSmith> | though you can also blow money on it if you want |
| 05:41 | <zcorpan> | but you can buy it if you want |
| 05:41 | MikeSmith | is MikeSmith btw |
| 05:41 | <MikeSmith> | Hixie: looking now |
| 05:42 | <artenix> | Mike tnx! |
| 05:43 | <artenix> | I must go. Thank you for all the hard work You have been doing on HTML |
| 05:44 | <zcorpan> | see ya |
| 05:45 | <MikeSmith> | Hixie: http://lists.w3.org/Archives/Public/public-html/2011Jan/0158.html |
| 05:45 | <MikeSmith> | closed without prejudice |
| 05:45 | <Hixie> | oh i meant a decision |
| 05:45 | <MikeSmith> | oh |
| 05:45 | <Hixie> | not the ones that time out |
| 05:45 | <Hixie> | sorry, i was unclear |
| 05:45 | <MikeSmith> | so none |
| 05:45 | <MikeSmith> | I think |
| 05:45 | <MikeSmith> | as far as decision-decisions |
| 05:46 | <MikeSmith> | but note that Paul was away since Christmas |
| 05:46 | <MikeSmith> | I think |
| 05:47 | <MikeSmith> | so perhaps some are waiting til they can meet together |
| 05:52 | <Hixie> | i could have sworn they had made a decision recently |
| 05:52 | <Hixie> | oh well |
| 05:52 | <Hixie> | thanks anyway |
| 05:53 | <MikeSmith> | othermaciej: see logs |
| 05:53 | <othermaciej> | oh man, I have to read? |
| 05:54 | <MikeSmith> | heh |
| 05:54 | <MikeSmith> | pretend it's code that you need to debug |
| 05:54 | <MikeSmith> | or review |
| 05:55 | zcorpan | doesn't find any decisions in his last month of public-html email containing the word 'decision' |
| 05:58 | <othermaciej> | MikeSmith: which part of the logs should I attend to? |
| 05:58 | <othermaciej> | I don't think any decisions have been published since before the holidays |
| 06:12 | <MikeSmith> | othermaciej: yeah, that was all I was pinging you about |
| 09:22 | <danbeam> | re-posted from #html5: sorry if this question has been asked and answered a ton already, but given that HTML5 is now just HTML, are efforts in promoting and branding the newer features in browsers as "HTML5" going to continue? |
| 09:22 | <danbeam> | (or is that not really a big concern of this channel/group?) |
| 09:24 | <jgraham> | danbeam: It seems highly likely that people will continue to use html5 as a marketing term |
| 09:27 | <danbeam> | jgraham: I agree this is likely. Perhaps I'm being pedantic, but aren't they're basically promoting a non-existent specification if they continue "repping" HTML5? |
| 09:27 | <danbeam> | aren't they* |
| 09:28 | <zcorpan> | danbeam: w3c still calls its spec "HTML5" |
| 09:28 | <danbeam> | (though I guess there is a snapshot of a semi-formed "HTML 5" specification, right?) |
| 09:30 | <jgraham> | danbeam: It helps if you think of "HTML5 as being 'The group of technologies that make up the Open Web Platform c. 2010' |
| 09:30 | <jgraham> | HTML is sone component of that (and continually evolves). CSS is another (and continuously evolves) |
| 09:31 | <danbeam> | jgraham: yeah, I've kind of figured that empirically along the way |
| 09:31 | <danbeam> | but it's just kind of weird to have multiple versions of HTML, CSS, ECMAScript, etc. |
| 09:31 | <danbeam> | but they all converge in one unifying concept |
| 09:32 | <danbeam> | of *** HTML5 *** |
| 09:32 | <danbeam> | haha |
| 09:32 | <danbeam> | it just seems very atypical of the whole process |
| 09:33 | <jgraham> | danbeam: It is, of course, insane |
| 09:33 | <jgraham> | But marketing never seems to be about rationality |
| 09:33 | <danbeam> | (and possibly hurtful, as now more people must agree to things to move forward, though I guess specs always have open requests for comments open to anybody) |
| 09:34 | <webr3> | does any of this/that matter? |
| 09:34 | <danbeam> | jgraham: marketing isn't rational as its consumers aren't often aren't either, :P |
| 09:35 | <danbeam> | webr3: any of what? the marketing or the merging of specifications? |
| 09:38 | <zcorpan> | http://www.w3.org/QA/2011/01/the_html5_logo_conversation.html |
| 10:00 | <hsivonen> | zcorpan: I added a listener for the playing event to webm.html5.org |
| 10:19 | <zcorpan> | hsivonen: nice |
| 10:24 | <zcorpan> | hsivonen: http://www.webmfiles.org/demo-files/ has two webm videos. not sure if they're any improvement though |
| 10:25 | <hsivonen> | zcorpan: I posted to webm-discuss asking if it's ok to make a test file that shows the WebM logo |
| 10:26 | <hsivonen> | zcorpan: I'm thinking either way I'll put the text WebM there and make a green checkmark fade in |
| 10:27 | <hsivonen> | now it's just a question of whether the "WebM" text can be the actual logo |
| 12:24 | <annevk> | http://www.whatwg.org/specs/web-apps/current-work/complete/ header looks a bit ugly imo |
| 12:27 | <benschwarz> | annevk: do something about it :) |
| 12:28 | <annevk> | whoa snow?! |
| 12:28 | <annevk> | weather wtf |
| 12:28 | <Peter`> | what? |
| 12:28 | <annevk> | benschwarz, nah, Hixie can change that |
| 12:29 | <annevk> | Peter`, lots of white powdery stuff in my backyard |
| 12:29 | <Peter`> | Nothing around here luckily |
| 12:29 | <annevk> | unless this is nuclear fallout, pretty sure it is snow |
| 12:30 | <espadrine> | annevk: I think it is nuclear. We have it here in Lyon, France too. |
| 12:31 | <annevk> | makes sense |
| 12:31 | <thiessenp> | annevk: no snow in Amsterdam, must have missed us |
| 12:31 | <Peter`> | thiessenp: I'm in Amsterdam too, hence my answer :) |
| 12:32 | <thiessenp> | Peter': had no idea. Are you near the center? |
| 12:33 | <Peter`> | No, Zeeburg / Amsterdam East |
| 12:36 | <thiessenp> | Peter': was going to ask if you wanted to grab a coffee/beer after work but I suspect your as lazy as me distance wise so ... :) |
| 12:37 | <Peter`> | I have a meeting in 20 minutes anyway, perhaps another time :) I'll keep it in mind |
| 12:37 | <Peter`> | (and have to go shortly after) |
| 12:37 | <thiessenp> | Peter': cool ttyl (may the meeting be short and painless :) |
| 12:40 | <annevk> | thiessenp, there's fronteers meetups every now and then |
| 12:40 | <annevk> | I wonder if there are enough Dutch people for a HTML5/WHATWG-type thing |
| 12:41 | <thiessenp> | annevk: I remember hearing something about fronteers - I'll look for a mail group or something. (brb) |
| 12:45 | <thiessenp> | annevk: btw: would be up for any WHATWG type meetings in Amsterdam |
| 12:46 | <annevk> | thiessenp, fronteers.nl it is, there's no mailing list, but there is #fronteers here on Freenode (Dutch channel) |
| 12:47 | <thiessenp> | annevk: nice - thanks! |
| 13:27 | <hsivonen> | annevk: I see you didn't summarize the solution to the TF use case assigned to you |
| 13:28 | <annevk> | I can do that |
| 13:28 | <annevk> | I forgot the goals of drafting the use cases, they include potential solutions? |
| 13:34 | <annevk> | hsivonen, I added a potential solution section |
| 13:36 | <annevk> | http://www.amazon.com/Definitive-Guide-HTML5-Video/dp/1430230908/ |
| 13:39 | <annevk> | I think I should maybe add the XML->XML one too |
| 13:45 | <annevk> | If anyone wants to have access to the blog or WHATWG twitter account for some reason just say so. This has always been our policy but it is not stated anywhere so I should probably repeat it every now and then. |
| 13:46 | <annevk> | Or maybe I should introduce a FAQ entry though I doubt regular contributors read that... |
| 13:57 | <hsivonen> | annevk: I completed my ACTION as well |
| 13:57 | <hsivonen> | annevk: not sure if putting everything on one page was a good idea |
| 13:58 | <annevk> | yours is quite big |
| 13:58 | <annevk> | had not expected that |
| 13:58 | <annevk> | feel free to ignore my question |
| 13:58 | <annevk> | we can create separate pages instead |
| 14:07 | <hsivonen> | got an explanation to the Yandex bot problem. I had been serving 503 at the moment when they tried to fetch robots.txt |
| 14:30 | <MikeSmith> | in Web IDL, for a particular method, how do I indicate an exception that method can throw? |
| 14:30 | MikeSmith | looks around for examples |
| 14:30 | <MikeSmith> | oh, just "throws" maybe |
| 14:32 | <MikeSmith> | ...or "raises" |
| 14:38 | <annevk> | I wonder why people want to put that in the IDL |
| 14:39 | <annevk> | hmm, maybe it does make some sense, but it makes the IDL look bloated |
| 14:43 | <hsivonen> | hey, someone is selling @font-face licensing finally: http://www.fontspring.com/fonts/exljbris/museo-sans |
| 14:43 | <hsivonen> | (without forcing typekit or such) |
| 14:43 | <hsivonen> | +50% to the price for the @font-face license |
| 14:44 | <zcorpan> | bah, i was going to tweet "A person who thinks (s)he is writing "stable" HTML 4.01 gets his/her content processed by the same ever-evolving code that processes the content made by a person who thinks (s)he is using the HTML5 draft standard." from http://lists.w3.org/Archives/Public/public-html-xml/2011Jan/0041.html but it doesn't fit in 140 chars |
| 14:45 | <hsivonen> | "All OpenType features must be removed from the licensed font." boo |
| 14:47 | zcorpan | made it shorter |
| 14:48 | <zcorpan> | maybe i should start tweeting in a format where i make use of the high bits in the utf-16 code units to fit more text into 140 utf-16 code units |
| 14:52 | <karlcow> | zcorpan: or tweet in Japanese or Chinese |
| 14:52 | <karlcow> | great compression scheme |
| 14:52 | <Workshiva> | Forget base64, use baseCJK |
| 14:53 | <zcorpan> | ≁⁰敲獯渠睨漠瑨楮歳 |
| 14:54 | <Philip`> | You should gzip-compress it too |
| 14:54 | <zcorpan> | (chinese does better than the above though) |
| 14:55 | <hsivonen> | is there a greasemonkey script, bookmarklet or some such for decoding? |
| 14:56 | <zcorpan> | i guess my scheme of just filling in the unused bits is lossy since you could get lone surrogates |
| 14:57 | <jgraham> | Or you could, y'know start a blog that allowed you to publish entries as long as you like |
| 14:57 | <karlcow> | :) I wish we could tweet QR code |
| 14:58 | <jgraham> | You could even push part of the entry to twitter if you like the network effects |
| 14:59 | <zcorpan> | jgraham: not long enough to be a blog entry :P |
| 15:01 | <annevk> | +1 to zcorpan blogging |
| 15:05 | <jgraham> | zcorpan: Plenty of people do short-form links_qoute/commentary as part of blogging e.g. http://simonwillison.net/ |
| 15:06 | <illtron> | I've eaten a *lot* of food, but none of it has ever killed me. |
| 15:07 | <illtron> | aaaannnd that was supposed to be in #5by5, not #whatwg. apologies |
| 15:08 | <zcorpan> | illtron: clearly you should eat more |
| 15:09 | <illtron> | i'm not eating a damn thing until I get to the store to buy some more e. coli flavored bbq sauce |
| 15:16 | <annevk> | food sounds good |
| 15:23 | <annevk> | http://arstechnica.com/web/news/2011/01/html-to-lose-the-version-number.ars -- also has comments |
| 16:09 | <webr3> | is the microdata DOM API implemented in any browsers, or is implementation planned? |
| 16:09 | <hsivonen> | webr3: planned for Firefox |
| 16:10 | <webr3> | hsivonen, cheers - and just the person, I had a question for you too :) would you say Harry's comments here are a fair sumamry wrt xmlns http://lists.w3.org/Archives/Public/public-lod/2011Jan/0213.html ? |
| 16:11 | <webr3> | his first paragraph that is |
| 16:12 | <hsivonen> | it is true that one thing that makes Namespaces annoying is that each identifier is a pair of strings instead of one string |
| 16:12 | <hsivonen> | and it is true that RDF identifiers are single strings |
| 16:13 | <hsivonen> | but prefix-based indirection in RDF flavors still shares other flaws with Namespaces |
| 16:13 | <hsivonen> | so you can't just concatenate the two strings and declare all problems of Namespaces solved |
| 16:15 | <webr3> | ack I wasn't planning to get in to that one, and it wasn't why i was asking either, was trying to figure out the problems with xmlns heritage itself, especially in regards to concatenating the two parts together (I couldn't find it defined in the related spec!) |
| 16:15 | <webr3> | ty for feedback though :) |
| 17:00 | <TabAtkins> | Argh, I don't understand why it's so hard to give a simple listing of a script's alphabet, for use as list markers. |
| 17:01 | <TabAtkins> | Of the very first script listed here, they have 58 characters listed (5 of them combining characters), and 53 codepoints listed. |
| 17:02 | <TabAtkins> | And it's not what you think, where they just omitted the combiners. Instead, they omitted four of the normal characters and *one* of the combiners. |
| 17:05 | <Xano> | I just read the blog post on no longer using version numbers for HTML. I understand why it's been done, but I cannot shake the feeling this is *very* bad for documentation. |
| 17:05 | <TabAtkins> | Nah, you've still got the ability to refer to versions. Just use the "Last Updated" date. |
| 17:06 | <TabAtkins> | If you tried to document "HTML5" a few months ago, your documentation is already out of date. |
| 17:07 | <Xano> | Say an API is considered final, but two years later undergoes changes to make it better. Conceptually, this would mean two different versions two me. Perhaps browsers will only support one version (preferably the latest), but conceptually the two remain different two me |
| 17:07 | <Xano> | "Last Updated" is a very, very relative concept |
| 17:07 | <TabAtkins> | I don't understand what's relative about a date. |
| 17:07 | <Xano> | *two me -> for to me |
| 17:07 | <Xano> | Ah, the date, my bad |
| 17:09 | <Xano> | Are there any guidelines for how frequently to update the standard? Because it'll be harder to track changes if they are made more than once a year. The dates are different, yes, but imagine response like "Oh, wait, there have been how many updates this year?" |
| 17:09 | <TabAtkins> | The standard is updated continuously and as necessary. |
| 17:09 | <TabAtkins> | In practice, that means a few updates a day right now. |
| 17:10 | <Xano> | I must note I'm a fan of development cycles (development -> alpha/beta/rc -> final) |
| 17:11 | <Xano> | During development most people know things can still change and that it's not wise to write tonnes of docs precisely because of that |
| 17:11 | <TabAtkins> | Unfortunately, this is the web. Something only becomes "final" when it's obsolete. |
| 17:11 | <Xano> | I'm thinking yearly cycles here |
| 17:11 | <TabAtkins> | However, individual sections of the spec become stable as implementations appear. |
| 17:12 | <Xano> | I'm just 'worried' it'll become hard to keep up |
| 17:13 | <TabAtkins> | It won't be any harder than it has been for the past 5 years that the spec has been developing. ^_^ |
| 17:13 | <Xano> | IMHO versions are not there to mark things as final, but to help people keep up |
| 17:13 | <Xano> | TabAtkins: True, but that's the idea of a development phase |
| 17:14 | <TabAtkins> | The problem is that the subset of things that are stable enough to shapshot is very arbitrary, based entirely on whether several browsers have implemented it or not. |
| 17:14 | <Xano> | In my experience releases are great ways to push forward, because 90% of all people are not going to use something that's still in development anyway, because things are going too fast for them. |
| 17:14 | <Xano> | THen agian, my experience does not extend to writing web standards, so I may be entirely wrong here |
| 17:14 | <bfrohs> | Xano: It rarely matters what the spec says. It matters what's supported. So, may I suggest: http://caniuse.com/ |
| 17:14 | <TabAtkins> | The spec itself tracks whether features have been implemented, and there are other sites on the web that do similar things. |
| 17:15 | <bfrohs> | The spec helps to guide implementors and developers when using the features--not so much in deciding which features to use. |
| 17:16 | <Philip`> | HTML4 was stable for a decade but that didn't mean you could trust browsers to have complete correct support for everything it defines - you still had to figure out exactly what features worked in which browsers, and avoid the ones that weren't well supported |
| 17:16 | <Xano> | I basically know the philosophy behind HTML(5). Is is truly about paving the cowpaths, or does it also help define how things should be best implemented? |
| 17:16 | <TabAtkins> | Both. |
| 17:16 | <Philip`> | so HTML(5) being a moving target doesn't change that |
| 17:17 | <TabAtkins> | The spec defines things so browsers can work in the same direction. Browsers implement things, so the spec has to match them if it wants to accurately describe reality. |
| 17:18 | <Xano> | FOr end users it's important to know when and how things are implemented consistently by browser makers, so they can use them |
| 17:18 | <Xano> | But if those implementations are still under development, they're not very useful for most end users, I guess. |
| 17:18 | <TabAtkins> | Yup, and that has never been accurately communicated by having a "final version" or even a "snapshot". It's always been communicated by community knowledge. |
| 17:19 | <Xano> | I guess it's just a matter of the lesser of two evils, right? |
| 17:19 | <TabAtkins> | Like Philip said, HTML4 was stable and final for a decade, but you still can't use it to determine what's usable. |
| 17:19 | <TabAtkins> | Well, most useful of the two evils. |
| 17:19 | <Xano> | It's not good for documentation, but that's just how things go |
| 17:19 | <Xano> | TabAtkins: fair enough |
| 17:19 | <Xano> | :) |
| 18:31 | <annevk> | It seems at least some of the confusion stems from what zcorpan tweeted earlier today. People do not realize HTML never had versioning. |
| 18:33 | <annevk> | Or that we never implemented HTML4 for that matter... |
| 18:44 | <TabAtkins> | The action that a browser takes if you drop a file into a page that doesn't have any dropzones is undefined, right? |
| 18:44 | <TabAtkins> | Normally browsers just try to load the file as if you'd navigated to it as a file: url. |
| 18:46 | <annevk> | It probably is defined actually. |
| 18:46 | <annevk> | Because we had file drag & drop before dropzones. |
| 18:46 | <annevk> | I suspect that what you suggest might be the default action in some browsers, but you can override that from script. |
| 18:46 | <TabAtkins> | Right; the default action is just what I'm talking about. That part's UA-defined, right? |
| 18:47 | <TabAtkins> | We're thinking of changing our behavior if you drag a file into a page that has dropzones, but drop it onto something that's not a dropzone. We'd like to just ignore the drop in this circumstance. |
| 18:48 | <annevk> | Pretty sure that must be UA-defined |
| 18:48 | <TabAtkins> | This would help, for example, people using GMail, if they're a little inaccurate and miss dropping the file into a message. |
| 19:12 | <Hixie> | annevk: do you mean the heading is ugly? the smallcaps? |
| 19:12 | <Hixie> | cos i agree, i was just seeing if it would grow on me |
| 19:13 | <Hixie> | i'll change it back in a bit i think |
| 19:16 | <Hixie> | i guess i should go through the blog and collect the questions |
| 20:44 | <Ms2ger> | Hixie, might be good to redirect http://hixie.ch/specs/css/dom/altss/altss to cssom |
| 20:46 | <annevk> | Hixie, yeah, the smallcaps |
| 20:47 | <Ms2ger> | Hey, the small caps looks really good on http://html5.org/specs/dom-parsing.html :) |
| 20:47 | <Hixie> | Ms2ger: is that part of cssom done yet? i thought it was still very much a wip. |
| 20:47 | <Hixie> | annevk: yeah i'll prolly change that soon. |
| 20:48 | <Ms2ger> | Dunno, less so than your spec? |
| 20:48 | <Hixie> | (fwiw when i do change it if you want to keep the caps set class=allcaps on the h1) |
| 20:48 | <Hixie> | (or whatever class i have set on the html spec today) |
| 20:48 | <Hixie> | Ms2ger: dunno. |
| 20:48 | <Hixie> | Ms2ger: not like anyone reads that hixie.ch spec anyway. |
| 20:48 | <Ms2ger> | Bz does |
| 20:49 | <Ms2ger> | Well, mentioned it, at least |
| 20:49 | <annevk> | I would say the CSSOM part of that is more mature |
| 20:49 | <annevk> | I worked on that actually and fixed a few things |
| 20:49 | <Hixie> | k |
| 20:49 | <Hixie> | i can add a note at the top |
| 20:50 | <Hixie> | what url should i redirect to? |
| 20:50 | <annevk> | Ms2ger, can you remove the PDF link from DOM Range? |
| 20:50 | <Ms2ger> | Sure |
| 20:51 | <annevk> | Hixie, http://dev.w3.org/csswg/cssom/ |
| 20:51 | <Hixie> | done |
| 20:51 | <annevk> | it's the first two sections of section 5 |
| 20:51 | <Hixie> | hey, the w3c changed their mind on what the logo means |
| 20:51 | <Hixie> | my head hurts trying to work out wtf they're doing |
| 20:51 | Ms2ger | doesn't try |
| 20:53 | <annevk> | I think because of the feedback they de-emphasized that it now includes CSS |
| 20:53 | <annevk> | well, said that it does not |
| 20:53 | <othermaciej> | does the logo that's only about the HTML5 spec still have appendages that let you badge it with non-HTML5 technologies? |
| 20:53 | <annevk> | so that part stayed |
| 20:54 | <hsivonen> | hmm. Grubar has reached an ad hominem level when writing about WebM and referring to the beards of the FSF folks |
| 20:54 | <hsivonen> | *Gruber |
| 20:54 | <annevk> | because these technologies are compatible with HTML5 |
| 20:54 | <annevk> | or something like that is the reasoning |
| 20:54 | <annevk> | http://www.w3.org/QA/2011/01/the_html5_logo_conversation.html has some information |
| 20:57 | <Hixie> | my favourite response to the spec name thing btw was w3c's official response from ij, which said that the w3c "remained" "the" standards organisation for html5 |
| 20:57 | <Hixie> | not like they're bitter or anything |
| 20:58 | <Ms2ger> | Well, they're the only one for HTML5 now, I guess |
| 20:58 | <Hixie> | yeah, that's why i'm not complaining :-) |
| 20:59 | <Hixie> | just thought it was amusing that that was the thing they were most worried about conveying |
| 20:59 | <Ms2ger> | annevk, done |
| 21:00 | <annevk> | that's also what our detractors tweeted |
| 21:14 | <Hixie> | "You had your chance. Developers and browser makers were listening. Now the browser makers have no one to listen to and itâs all up to them. In lieu of any guidance, the browsers are now independent. I sure wish MS would adopt webkit!" |
| 21:15 | <jcranmer> | ah yes, the idiots |
| 21:17 | <bfrohs> | I saw that earlier--had a good laugh :) |
| 21:17 | <TabAtkins> | Where's that one from? The blog? |
| 21:17 | <bfrohs> | http://blog.whatwg.org/html-is-the-new-html5#comment-42356 |
| 21:18 | <Hixie> | "idiots" seems a bit harsh |
| 21:18 | <TabAtkins> | Man, comment #57 is really good. In a good way, not a sarcastic way |
| 21:19 | <Hixie> | it seems to be a common misconception that standards committees are independent from the implementors |
| 21:21 | <Ms2ger> | For the W3C, is it really a misconception? |
| 21:22 | <TabAtkins> | Yes? The W3C is full of implementors. |
| 21:22 | <othermaciej> | well there's WGs with no browser implementors in them |
| 21:22 | <othermaciej> | generally their specs don't get implemented |
| 21:22 | <TabAtkins> | Those are the ones that make useless things, right? |
| 21:22 | <Ms2ger> | I guess they would disagree |
| 21:23 | <othermaciej> | IETF is controlled by server implementors |
| 21:29 | <MikeSmith> | is it just me or is the log page borked? |
| 21:29 | <MikeSmith> | http://krijnhoetmer.nl/irc-logs/ |
| 21:29 | <MikeSmith> | krijnh: ↑ |
| 21:34 | <TabAtkins> | MikeSmith: Yeah, borked for me too. |
| 21:34 | <MikeSmith> | k |
| 21:34 | <MikeSmith> | somebody wake up the programmer! |
| 21:38 | <dglazkov> | I told you to keep the versions. Now we'll never know how it broke. |
| 21:38 | <TabAtkins> | Haha |
| 21:38 | <dglazkov> | :) |
| 21:46 | <karlcow> | https://secure.grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information |
| 21:47 | <Rik`> | karlcow: with that kind of title, I want a valid certificate |
| 21:48 | <karlcow> | yes :) |
| 21:48 | <karlcow> | I know this is the bad part of the experience |
| 21:48 | <karlcow> | reaching the site |
| 21:48 | <karlcow> | ;) |
| 21:49 | <karlcow> | the attack is very similar to the visited link in css. |
| 21:50 | <TabAtkins> | Yeah, except harder to fix, because it depends on every site with logins being smart about how they expose information. |
| 21:51 | <karlcow> | yep |
| 21:51 | <Rik`> | or disabling mashups :) |
| 21:51 | <karlcow> | +1 ;) |
| 21:52 | <TabAtkins> | Heh, yeah, disable cross-origin for every resource. |
| 21:52 | <TabAtkins> | And then watch the web burn. |
| 21:53 | <karlcow> | I'm already burning of excitment |
| 21:55 | <Rik`> | well, people would write small proxies like they do for XHR |
| 22:00 | <gsnedders> | karlcow: I wonder what would happen if you stopped firing the error event |
| 22:00 | <TabAtkins> | gsnedders: At least for cross-origin loads? |
| 22:00 | <gsnedders> | TabAtkins: Oh, yeah, that's what I meant. |
| 22:00 | <gsnedders> | TabAtkins: There's already one place where that's the case, no? |
| 22:01 | <TabAtkins> | With <img>, can't you still detect success vs error by measuring the size afterwards? |
| 22:01 | <paul_irish> | yup. |
| 22:10 | <gsnedders> | iframes don't fire error events in the cross-origin case. |
| 22:10 | <gsnedders> | It'd make sense to extend that elsewhere, IMO |
| 22:12 | <TabAtkins> | Iframes also dont' resize themselves based on their contents. |
| 22:12 | <gsnedders> | This is true. |
| 22:13 | <TabAtkins> | (Unless they're seamless, which then potentially exposes the same problems.) |
| 22:14 | <gsnedders> | But it would stop the status-code based attack in every other case. |
| 22:15 | <TabAtkins> | Yes. |
| 22:16 | <dglazkov> | I want CSS measurements from a point: |
| 22:16 | <dglazkov> | var point = new RelativePoint(element, x, y); |
| 22:17 | <dglazkov> | alert(point.top.percent); // shows distance from the top of element in percentages |
| 22:17 | <Hixie> | "What about people who donât want to be constantly updating their browser⦠certain parts of pages, or whole pages, will become invalid because on feature was changed a few weeks after the last release?" |
| 22:17 | <Hixie> | how did people think this worked before? |
| 22:17 | <Hixie> | http://blog.whatwg.org/html-is-the-new-html5#comment-42382 is kinda funny |
| 22:19 | <TabAtkins> | dglazkov: <3 |
| 22:19 | <TabAtkins> | Hixie: Hahahahahaha |
| 22:19 | <dglazkov> | annevk: ^^^^ (my example, not Hixie's sensitivity to haters) |
| 22:20 | <dglazkov> | he's probably asleep or smth |
| 22:22 | <boogyman> | Ian, they probably believed that no portion of the "New" HTML spec was implemented until the specification was put into the status previously known as "Recommendation" |
| 22:22 | <Hixie> | boy is that a misconception |
| 22:23 | <Hixie> | surely though nobody would have missed all the browsers screaming about how they implement html5 |
| 22:30 | <annevk> | dglazkov, interesting idea |
| 22:31 | <TabAtkins> | dglazkov: You'd want the ability to specify the box of the element, too - content vs padding vs border vs margin. |
| 22:33 | <dglazkov> | the use case is: I want to position a thumb inside of the slider in response to a mouse event |
| 22:34 | <dglazkov> | with this API, all I have to do is ask for percentage and dumbly set left (or top) to whatever comes out |
| 22:35 | <annevk> | I had thought to extend getBoundingClientRect() and friends |
| 22:35 | <annevk> | but probably new APIs we come up with need to take into account transforms somehow |
| 22:36 | <dglazkov> | annevk: yes! they totally should. |
| 22:36 | <karlcow> | http://www.quirksmode.org/blog/archives/2011/01/linkbait_4.html |
| 22:36 | <TabAtkins> | Similarly, RelativeLength, which needs to be canonicalized against an element (to convert between px and em) and a property (to convert to/from %). |
| 22:36 | <karlcow> | >CSS variables, nesting, and modules are finally coming. Not from the W3C, of course; it has completely ignored our pleas for years. Google will bring salvation, apparently. |
| 22:37 | <karlcow> | >Incidentally, if all this will be built into WebKit it will be on mobile that these new features will be available first. |
| 22:37 | <dglazkov> | All hail to almighty google |
| 22:37 | <TabAtkins> | Where'd you find that? I guess they missed that I'm part of CSSWG. |
| 22:37 | <karlcow> | TabAtkins: the link just before |
| 22:37 | <karlcow> | @ppk on twitter |
| 22:37 | <TabAtkins> | Dammit, ppk. |
| 22:38 | <Rik`> | And I mean CSS variables has a draft by glazou and dhyatt |
| 22:38 | <karlcow> | yep yep |
| 22:38 | <jamesr_> | yeah those notorious google hackers |
| 22:38 | <TabAtkins> | Rik`: Different draft than what we're going with, though. |
| 22:39 | <karlcow> | I would still be working at W3C I would have written a blog post on /QA explaining the history of discussions |
| 22:40 | <Rik`> | it looks like PPK thinks there is no implementors in the W3C |
| 22:41 | <dglazkov> | and that WebKit is only on mobile. |
| 22:41 | <TabAtkins> | I think he's implying that mobile will be the first "safe place" to use it. |
| 22:41 | <dglazkov> | darnit, I am turning into a hater. Shutting up now. |
| 22:42 | <TabAtkins> | karlcow: Write it anyway and submit it to them. |
| 22:42 | <TabAtkins> | Because honestly even I lack some of the context. |
| 22:42 | <TabAtkins> | (Though I do know about the last real effort, particularly Hyatt/glazou's stuff.) |
| 22:44 | <Rik`> | oh and last year I asked glazou about nesting and he told me that would be a big perf hit |
| 22:44 | <TabAtkins> | Haha, the wife and I are such nerds. I want http://biowarestore.com/mass-effect/mass-effect-mini-lithos/me2-tali-mini-litho , she wants http://biowarestore.com/dragon-age/dragon-age-ladies-apparel/i-love-alistair-womens-tee |
| 22:44 | <TabAtkins> | Rik`: That... that doesn't even make sense. |
| 22:45 | <TabAtkins> | Nesting is just syntax sugar for not nesting. |
| 22:46 | <TabAtkins> | foo { & bar { prop:value; } & baz { prop: value; }} === foo bar { prop: value; } foo baz { prop: value; } |
| 22:47 | <Rik`> | that felt weird at the time but we haven't got the opportunity to discuss it more than 30 seconds so :) |
| 22:47 | <TabAtkins> | Now, if you do the syntax wrong, it is indeed bad, because you need lots of lookahead. |
| 22:47 | <TabAtkins> | But we're not making that mistake. |
| 22:48 | <jamesr_> | TabAtkins: they map to descendant selectors? what if you really want child selectors? |
| 22:48 | <TabAtkins> | jamesr_: foo { & > bar { prop: value; }} |
| 22:49 | <TabAtkins> | foo { &:hover { prop: value; }} === foo:hover { prop: value; } |
| 22:49 | <jamesr_> | besides looking like total line noise that's pretty cool |
| 22:49 | <TabAtkins> | Well of course it does when it's single-lien. |
| 22:49 | <TabAtkins> | When properly indented, it's very readable. |
| 22:50 | <Hixie> | what on earth does that mean |
| 22:50 | <Hixie> | line noise is right :-P |
| 22:50 | <TabAtkins> | I'm writing my blog post about it right now. There will be indented examples. |
| 22:51 | <bfrohs> | That could save a ton of repetition in CSS files... and help save time/prevent mistakes if a class/tag/id ever changes :) |
| 22:51 | <TabAtkins> | Precisely. |
| 22:56 | <bfrohs> | TabAtkins: Does it support multiple tags for each level? e.g. - body { section, article { strong {prop:value; } } } |
| 22:56 | <TabAtkins> | bfrohs: Of course. |
| 22:56 | <bfrohs> | TabAtkins: You're my hero :) |
| 23:02 | <Steve^> | This new CSS is effectively the same as Sass or less? |
| 23:02 | <TabAtkins> | Highly inspired, yeah. |
| 23:03 | <Hixie> | http://wiki.whatwg.org/wiki/FAQ updated based on theblog comments |
| 23:05 | <Steve^> | TabAtkins, what are the fundamental differences? |
| 23:06 | <chriseppstein> | Steve^: So far the biggest diff is some parser constraints and things have be kept declarative instead of sass's more imperative style. |
| 23:06 | <TabAtkins> | Steve^: Vars act like they should in a declarative language, unlike SASS where it can be assigned different values at different times. |
| 23:06 | <TabAtkins> | Then just some relatively minor syntax differences. |
| 23:07 | <chriseppstein> | TabAtkins: Lots of people are worried about nesting as a perf drag because descendent selectors are slow |
| 23:07 | <Steve^> | Less has constants, rather than variables |
| 23:08 | <TabAtkins> | chriseppstein: Nesting has no inherent relationship to descendant selectors. That's one of the things our syntax helps with. |
| 23:08 | <chriseppstein> | TabAtkins: how so |
| 23:09 | <TabAtkins> | foo { & > bar { prop: value; }} === foo > bar { prop: value; } |
| 23:09 | <chriseppstein> | right. you can do that in sass |
| 23:09 | <chriseppstein> | you can even omit the & |
| 23:09 | <Steve^> | exactly |
| 23:09 | <Steve^> | So how does the & help us? |
| 23:10 | <TabAtkins> | Yeah, so there's no perf hit that you wouldn't see otherwise. You're not forced to use descendant selectors. It's exactly as easy to write performant nested CSS as not. |
| 23:10 | <chriseppstein> | Steve^: body.foo & |
| 23:10 | <TabAtkins> | Steve^: When parsing CSS, if you don't have an explicit indication that "here there be nesting", you ahve to have lots of lookahead. |
| 23:10 | <TabAtkins> | In "foo { bar:hover a a a a a a { prop: value; }}", you don't know whether this is an element with a pseudoclass or a property named "bar" until you reach the {. |
| 23:10 | <Steve^> | hmm, not so sure about that |
| 23:11 | <Steve^> | ok, but does that matter? |
| 23:11 | <TabAtkins> | Yes. We try to minimize lookahead in CSS. |
| 23:11 | <chriseppstein> | TabAtkins: I agree. It's just a concern that people have. might want to make sure to note it in your post |
| 23:11 | <TabAtkins> | Except for a few minor places, we only have to do 1-token lookahead max. |
| 23:11 | <TabAtkins> | chriseppstein: Sure. |
| 23:11 | <Steve^> | Yea, nice to explain that. First glance it looks like less/sass but with more syntax |
| 23:12 | <Steve^> | TabAtkins, how would you nest a :hover? |
| 23:12 | <TabAtkins> | foo { &:hover { prop:value; }} |
| 23:13 | <TabAtkins> | (This is another benefit of our syntax over the no-explicit-indicator syntax.) |
| 23:13 | <Steve^> | Would you have mixins? |
| 23:13 | <TabAtkins> | You can use mixins and nesting together, yeah. |
| 23:14 | <chriseppstein> | TabAtkins: That's legal sass you just typed ;) |
| 23:14 | <Steve^> | So, you've added a & and restricting variables a little (so it's more like less, to my understanding) |
| 23:14 | <TabAtkins> | chriseppstein: Yeah, I'm just saying. |
| 23:14 | <chriseppstein> | Steve^: even less.js has & |
| 23:15 | <Steve^> | bah, less.js is a mess |
| 23:15 | <chriseppstein> | confirm |
| 23:15 | <Steve^> | I tried raising bugs and the developers didn't seem to care |
| 23:15 | <Steve^> | but it'll be nice for a CSS fallback |
| 23:16 | <chriseppstein> | you can use scss now :) we don't ignore bugs |
| 23:16 | <TabAtkins> | We're writing a preprocessor for our syntax anyway, so you'll be able to run it just like SASS/LESS, and use the new syntax now rather than a decade from now. |
| 23:16 | <Steve^> | chriseppstein, is that a typo of sass? |
| 23:16 | <chriseppstein> | scss is sass's css-based syntax |
| 23:16 | <TabAtkins> | Also, SASS may just add a mode that recognizes the spec syntax. |
| 23:16 | <Steve^> | ah |
| 23:16 | <TabAtkins> | alter scss to do so. |
| 23:17 | <chriseppstein> | TabAtkins: ya. maybe we'll just parse css in that mode |
| 23:18 | <TabAtkins> | If a spec says that UAs must block cross-origin loads, does CORS apply automatically or does the spec need to explicitly say "unless lifted by CORS"? |
| 23:19 | <TabAtkins> | s/loads/loads of a particular type of resource/ |
| 23:22 | <Steve^> | oh wow, Less have stopped the ruby version? |
| 23:23 | <chriseppstein> | Steve^: yes. it's deprecated |
| 23:23 | <Steve^> | when I tried it it was hot of the press, there was literally one decent blog post on it |
| 23:24 | <chriseppstein> | Steve^: Sass has been around for 4 years with the same active, maintainer. |
| 23:24 | <Steve^> | My super-critical bug was that urls in normal css files are relative to the css file location, whereas urls via less.js were relative to the site |
| 23:24 | <Steve^> | so it wasn't compatible with itself |
| 23:25 | <Steve^> | I'm not sure I see the point of less.js outside of development |
| 23:26 | <Steve^> | Why exclude that really small percentage of users and add an overhead? |
| 23:26 | <chriseppstein> | Steve^: right. even @cloudhead recommends using the server side version for any "real" use |
| 23:26 | <chriseppstein> | it can run on the server using node.js |
| 23:26 | <Steve^> | So.. they deprecated themselves? |
| 23:27 | <chriseppstein> | less.js can run in client and server |
| 23:27 | <chriseppstein> | the idea is pretty neat |
| 23:28 | <Steve^> | Are we actually saying that everyone has JS now though? |
| 23:29 | <chriseppstein> | ? |
| 23:30 | <Steve^> | yea, ignore me |
| 23:30 | <Steve^> | that's the official notice that it's bed time |
| 23:30 | <chriseppstein> | 'nite |
| 23:31 | <davidmurdoch_> | paul_irish told me to come in here and ask TabAtkins about this: http://jsfiddle.net/sBy6M/ |
| 23:31 | <TabAtkins> | I categorically refuse to answer questions about flexbox, since I'm writing a new version of it right now. ^_^ |
| 23:32 | <jamesr_> | davidmurdoch_: hmm, i guess setting display:block changes the replaced behavior? |
| 23:32 | <jamesr_> | i always get confused about how layout works with replaced elements (like iframes) |
| 23:32 | <davidmurdoch_> | are you sure. cus I've been at it for about 3 hours before I figure out that the docs were wrong (i think) |
| 23:32 | <Steve^> | wait... Chrome 10? |
| 23:32 | <jamesr_> | davidmurdoch_: can you file a bug on bugs.webkit.org, actually? |
| 23:32 | <jamesr_> | looks like an implementation bug |
| 23:32 | <TabAtkins> | They're display:inline, but inline replaced acts just like display:inline-block. |
| 23:32 | <Steve^> | I thought we were in 9 beta |
| 23:32 | <davidmurdoch_> | i'm on dev. |
| 23:32 | <jamesr_> | although like tab said flexbox is going to get changed |
| 23:33 | <Steve^> | crazy |
| 23:33 | <Steve^> | (not you, the version numbering) |
| 23:33 | <davidmurdoch_> | so, should I file the bug? |
| 23:34 | <TabAtkins> | I don't know. The behavior of current-draft flexbox feels dangerously underspecified, so I'm not certain what behavior is right and what is wrong. |
| 23:35 | <TabAtkins> | However! I suspect the problem is that only display:block element can actually be flexbox children. display:inline elements get wrapped in an anonymous block box. This can cause troubles similar to what you get with the table-* display values sometimes. |
| 23:35 | <Steve^> | How are Chrome going to get around the version numbering problem that Opera 10 found? |
| 23:35 | <TabAtkins> | Steve^: By powering through. |
| 23:35 | <TabAtkins> | We already know that there's some problems, but shrug. |
| 23:36 | <Steve^> | That is the Google way! |
| 23:36 | <Steve^> | Alright, night guys |
| 23:42 | <davidmurdoch_> | TabAtkins: i just tested it on a <span/> and found the same problem. |
| 23:42 | <TabAtkins> | That's consistent with what I just said. |
| 23:43 | <davidmurdoch_> | Yup, I was just checking. |
| 23:45 | <davidmurdoch_> | From the docs: "If inline-level elements are nested inside boxes, they get wrapped in an anonymous block which then takes part in the box layout." Wouldn't this mean that inline elements should behave exactly the same as block-level? |
| 23:45 | <davidmurdoch_> | sorry, i know you don't care to answer these questions. |
| 23:45 | <davidmurdoch_> | I'll check what firefox does. |
| 23:52 | <TabAtkins> | No, the thing that participates in layout is the block box, which you can't target or give any instructions to. |
| 23:52 | <TabAtkins> | davidmurdoch_: In particular, you can't tell it to flex. |
| 23:53 | <davidmurdoch_> | well, thats just confusing. :-) |
| 23:53 | <TabAtkins> | Yeah, anonymous blocks confuse a lot of people. |
| 23:54 | <TabAtkins> | They are an unfortunate necessity in many circumstances. |
| 23:54 | <davidmurdoch_> | Firefox 4 treats the containing element as inline-block... |
| 23:55 | <davidmurdoch_> | it ignores the height on the iframe and flexes it to match the box. |
| 23:55 | <davidmurdoch_> | ...it flxes the width to match the box as well. |
| 23:56 | <davidmurdoch_> | it ignores <span> completely |
| 23:56 | <davidmurdoch_> | http://jsfiddle.net/sBy6M/2/ |