| 01:01 | <othermaciej> | I wonder how Andy Clarke came to his conclusions about how to improve CSS |
| 01:14 | <spuffle> | got a link? :) |
| 01:17 | <othermaciej> | http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/ |
| 01:17 | <othermaciej> | http://www.stuffandnonsense.co.uk/malarkey/more/csswg_proposals/ |
| 01:17 | <othermaciej> | short version, he would like to get rid of implementors and have the W3C pay web designers to be on the working group full time |
| 01:17 | <othermaciej> | or something |
| 01:17 | <othermaciej> | because Opera sued Microsoft |
| 01:19 | <spuffle> | ahha |
| 01:19 | <spuffle> | always gotta make a bold statement |
| 01:25 | <spuffle> | defintely +1 for leadership |
| 01:26 | <spuffle> | It's just an opinion though, everyone is entitled to theirs |
| 01:40 | <othermaciej> | leadership is a good thing, given the right leader |
| 01:40 | <othermaciej> | mainly what puzzles me is why he thinks less implementor involvement would be good |
| 01:40 | <othermaciej> | I think a key problem is not enough implementor involvement |
| 01:40 | <othermaciej> | (and the fact that few other parties have the needed skills and the time to spend) |
| 01:43 | <spuffle> | he just wants to see it run like a business |
| 01:43 | <spuffle> | with a more corporate-style hierachy |
| 01:44 | <roc> | I think he's in "X isn't working, panic, let's try Y" mode |
| 01:48 | <othermaciej> | running it like a business certainly wouldn't involve removing the participants that are actual businesses |
| 01:48 | <othermaciej> | "let's treat it like a software project - get rid of the software vendors and let the users drive it from their wishlist" |
| 01:48 | <othermaciej> | that ain't how software gets shipped |
| 01:50 | <othermaciej> | damn, I posted some wordy blog comments |
| 01:53 | <jruderman> | i just read http://www.stuffandnonsense.co.uk/malarkey/more/css_unworking_group/ and i don't understand why he thinks Opera's antitrust complaint has anything to do with the development of CSS3 |
| 01:54 | <othermaciej> | me neither |
| 01:56 | <jruderman> | "I was surprised to learn that one of the reasons why CSS2.1 is only now nearing its candidate recommendation status is because its features are now widely supported by browsers." |
| 01:57 | <jruderman> | in reality, is it just because there are multiple interoperable implementations? |
| 01:57 | <jruderman> | in which case microsoft dragging its feet doesn't really slow things down |
| 01:58 | <othermaciej> | multiple interoperable implementations, and the fact that implementations showed problems |
| 01:58 | <othermaciej> | I think CSS2.1 may have actually already hit CR once and went back to WD |
| 01:59 | othermaciej | hopes it wasn't rude to answer the question about how to learn more about CSS internals with a suggestion to get involved w/ an open source browser engine |
| 01:59 | <othermaciej> | obviously, I have some selfish interests there |
| 02:01 | <hdh> | well, that's still a 1/3 chance :) |
| 02:02 | <othermaciej> | I think there's only 2 significant open source browser engines |
| 02:02 | <othermaciej> | but maybe I'm counting wrong |
| 02:03 | <hdh> | khtml isn't dropped yet |
| 02:05 | <hdh> | btw, who's the other maciej? |
| 02:09 | <othermaciej> | someone else |
| 02:34 | <roc> | othermaciej: I believe Dillo, links, and Amaya are all under active development |
| 02:35 | <roc> | oh, significant :-) |
| 02:36 | <othermaciej> | I don't think Dillo is |
| 02:36 | <othermaciej> | and trying to do QA on Amaya would just be depressing |
| 07:00 | <hsivonen> | Hixie: is there a design reason why video src='' overrides <source>s instead of being the last resort if no <source> matches? |
| 07:01 | <Hixie> | hsivonen: yeah, i thought it would be confusing for the test order to be different than the source order |
| 07:01 | <Hixie> | and i further thought it would look stupid for the two-codec case to have the two codecs at different indent levels and syntaxes |
| 07:02 | <hsivonen> | Hixie: it seems to me that having src='' as the last resort (if changed before any impl ships) would make the selection more resilient against partial implementations and would give a server-side sniffing point as the last resort |
| 07:03 | <hsivonen> | In particular, Anne's comments about Opera's implementation made me concerned that with the current spec a vendor shipping without <source> support would effectively poison the selection mechanism |
| 07:04 | <Hixie> | i agree with both points, but i don't think they justify the author confusion |
| 07:04 | <othermaciej> | I think it would be simplest for src to be the first resort |
| 07:04 | <hsivonen> | but if src='' were the last choice, that wouldn't be a problem |
| 07:04 | <Hixie> | now if a vendor shipped with just src="" and did poison the case, that would be a reason to change, but hopefully that won't happen |
| 07:05 | <Hixie> | <video src="3"><source src="1"><source src="2"></video> is extremely confusion imho |
| 07:05 | <hsivonen> | ok. |
| 07:05 | <Hixie> | er, my grammar sucks |
| 07:05 | <Hixie> | but you get the point |
| 07:05 | <othermaciej> | what about making the first src be the first to try? (I guess that would require video to have a type attribute if it doesn't already) |
| 07:06 | <Hixie> | that's more compelling, but i don't see why authors would want that. <video> doesn't have the attributes <source> does, and it looks weird: |
| 07:06 | <hsivonen> | part of the problem is that it's too easy to ship with semi-broken type support |
| 07:06 | <othermaciej> | It's also unfortunate that video has no good way to handle the "<video> is supported, but none of the codecs I want are available" case |
| 07:06 | <Hixie> | <video src="video.mpg"> |
| 07:06 | <Hixie> | <source src="video.ogg"> |
| 07:06 | <Hixie> | </video> |
| 07:07 | <Hixie> | othermaciej: i don't believe, by and large, that authors will care about that case |
| 07:07 | <othermaciej> | like say I wanted to use <video> with an Ogg source only, and otherwise fall back to a Java applet |
| 07:07 | <Hixie> | <object> use in the wild suggests that's far rarer than we would hope |
| 07:07 | <hsivonen> | I'm very pessimistic about the abilit of implementations to propertly introspec for dynamically loaded codecs |
| 07:07 | <othermaciej> | or use <video> with an H.264 source only, and otherwise fall back to a Flash or Quicktime plugin |
| 07:08 | <Hixie> | we do have events that fire if authors do want to handle that case |
| 07:08 | <Hixie> | and if it turns out to be common (which i seriously doubt) we can always support that later via some hack |
| 07:08 | <othermaciej> | I guess that's better than nothing |
| 07:08 | <hsivonen> | speaking applets, has anyone started an effort to implement <video> in IE using JS and Cortado? |
| 07:08 | <Hixie> | but i'm skeptical |
| 07:08 | <othermaciej> | what's Cortado? |
| 07:08 | <hsivonen> | othermaciej: pure Java Ogg/Theora/Vorbis player applet |
| 07:10 | <othermaciej> | thinking about video formats makes my brain hurt |
| 07:11 | <othermaciej> | but I do have the concern that if multiple browsers support <video> with different sets of codecs, per the current spec that makes life harder for authors than if only one browser supports <video> |
| 07:11 | <othermaciej> | (well, I guess it depends on how much they care about single encoding of the video vs. consistent API) |
| 07:11 | <othermaciej> | (but QuickTime offers something pretty close to the <video> API in the latest version, by design) |
| 07:12 | <othermaciej> | (and I suspect the same is doable with Flash) |
| 07:13 | <othermaciej> | anyway we'll see what happens |
| 07:13 | <othermaciej> | it's not hard to think of hacks to explicitly allow for such use |
| 07:15 | <Hixie> | if we can't get a common codec, changing the fallback rules will be the least of our problems |
| 07:16 | <hsivonen> | today embedding YouTube Flash involves pasting in magic boilerplate |
| 07:17 | <hsivonen> | it wouldn't be impossible to develop pasteable magic boilerplate that used native Ogg support in Opera and Gecko, XiphQT in Safari and Cortado in IE |
| 07:17 | <hsivonen> | far from ideal, though |
| 07:21 | <othermaciej> | not sure most web authors will do that much work to get non-browser-native support for a worse codec than Flash's non-browser-native support provides |
| 07:21 | <othermaciej> | yet another reason the codec situation sucks |
| 07:22 | <othermaciej> | (obviously some ideologically committed content providers like wikipedia would do so) |
| 07:22 | <hsivonen> | othermaciej: that depends on whether the authors are doing something that shows up on MPEG-LAs radar, I guess |
| 07:24 | <othermaciej> | fortunately still bandwidth and image formats have evolved to the point that patent-encumbered improvements are not worth it |
| 07:24 | <othermaciej> | audio could be close to that point |
| 07:24 | <othermaciej> | maybe video too someday |
| 07:24 | <othermaciej> | (withness the lack of excitement over JPEG2000) |
| 07:25 | <othermaciej> | *witness |
| 07:25 | <Hixie> | microsoft are really starting to royally piss me off with this EOT bullshit |
| 07:25 | <othermaciej> | are they still riding that horse? |
| 07:25 | <Hixie> | yet another reason to start the whatcsswg |
| 07:26 | <hsivonen> | othermaciej: not only is JPEG2000 legally undesirable, it isn't even technically competitive with the old JPEG even in the huffman form of the old JPEG when the level of compression you want is no visible artifacts |
| 07:26 | <othermaciej> | oh, I gotta read the latest bit of that thread |
| 07:26 | <hsivonen> | JPEG2000 is a win technically only if you want to compress so much that there are visible artifacts |
| 07:26 | <othermaciej> | that's sad |
| 07:26 | <Hixie> | othermaciej: i moved the thread to the public list |
| 07:27 | <hsivonen> | in that case, the artifacts of the old JPEG get more ugly faster than the JPEG2000 artifacts |
| 07:27 | <Hixie> | which i'm sure will make them so happy |
| 07:30 | <othermaciej> | their latest mail on the subject in the secret list is just embarassing |
| 07:31 | <othermaciej> | I can't believe they got pwned that hard and are still trying to argue their point |
| 07:35 | <hsivonen> | Did Björn send his message to any public archive later? |
| 07:36 | <MikeSmith> | hsivonen - which message from Björn do you mean? |
| 07:37 | <hsivonen> | MikeSmith: http://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0329.html |
| 07:37 | <othermaciej> | someone else could send the same information to a public list |
| 07:38 | <othermaciej> | although I'm not sure if the Microsoft request it was responsive to has been made public |
| 07:40 | <Hixie> | my new macbook pro has this weird thing where every now and then the network stalls |
| 07:40 | <MikeSmith> | so were the MS reps to the CSS WG aware of this already at the time of the face to face in Boston? |
| 07:40 | <Hixie> | just opening the wireless menu makes it work again |
| 07:40 | <Hixie> | i wonder what's up with that |
| 07:41 | <MikeSmith> | Hixie - is that when you're using a wireless connection or when you're using Ethernet? |
| 07:41 | <Hixie> | wireless |
| 07:42 | <MikeSmith> | I've not had a problem like that when using Airport, but I have when using my wireless HSDPA modem |
| 07:42 | <MikeSmith> | specifically when using Skype |
| 07:42 | <Hixie> | my mac mini hasn't ever had that as far as i know |
| 07:42 | <Hixie> | nor my powerbook |
| 07:42 | <Hixie> | but my mac book pro, and the macbook my girlfriend has, both have it |
| 07:45 | <hsivonen> | does anyone remember off-hand if Gecko/Opera/WebKit trim SVG enumerated-value attribute values before comparing against an internal token literal? |
| 07:45 | <MikeSmith> | Hixie - are you running Tiger on your other machines? |
| 07:45 | <hsivonen> | that is, does clip-rule=' nonzero ' work? |
| 07:46 | <Hixie> | the mac mini ran tiger then leopard, as did the macbook. the powerbook and the mac book pro are both tiger. |
| 07:49 | <othermaciej> | hsivonen: trim what? whitespace? |
| 07:50 | <hsivonen> | othermaciej: yes |
| 07:51 | <hsivonen> | this is interesting: http://lists.w3.org/Archives/Public/www-math/2007Nov/0007.html |
| 07:51 | <othermaciej> | not easy to tell from code |
| 07:51 | <hsivonen> | othermaciej: I guess I just have to write a test case or two |
| 07:51 | <hsivonen> | thanks |
| 10:51 | <Hemebond> | Where can I find a list of "problems" the WHATWG has with XHTML2? |
| 10:53 | <annevk> | If they are not in our FAQ I don't think we've written them up |
| 10:53 | <annevk> | Then again, the HTML5 draft does mention the relationship of HTML5 with XHTML2 |
| 10:53 | <Hemebond> | Hi Anne. |
| 10:54 | <Hemebond> | I'll go have another look. |
| 10:58 | <Hemebond> | Can't see anything in the FAQ. |
| 10:59 | <Lachy> | Hemebond, I don't believe any such list exists, but is there anything specific you would like to know about? |
| 11:00 | <Hemebond> | I wanted to read about the problems developers had implementing XHTML2. |
| 11:00 | <Hemebond> | I remember when I first questioned the direction of HTML5, the respondent said XHTML2 was a mess to implement. |
| 11:00 | <Hemebond> | Too many gaps. |
| 11:00 | <Hemebond> | Too much room for interpretation. |
| 11:01 | <Lachy> | yes, things are too underspecified to be implemented |
| 11:01 | <Lachy> | for instance, there is no error handling defined anywhere |
| 11:01 | <Hemebond> | XHTML2 is still under development, no? |
| 11:02 | <Lachy> | yes |
| 11:03 | <Hemebond> | "All the browser vendors have already said they will support HTML 5 (yes, that includes MS) and all but MS have said they won't support XHTML 2" |
| 11:03 | <Hemebond> | Is that true? |
| 11:03 | <Lachy> | where is that quoted from? |
| 11:03 | <Hemebond> | Slashdot comment. |
| 11:03 | <Lachy> | link? |
| 11:04 | <Hemebond> | http://developers.slashdot.org/article.pl?sid=07/12/16/1656245&from=rss |
| 11:04 | <Hemebond> | http://developers.slashdot.org/comments.pl?sid=390646&cid=21718302 < actual comment |
| 11:04 | <Hemebond> | Wait... no it's not |
| 11:04 | <Hemebond> | http://developers.slashdot.org/comments.pl?sid=390646&cid=21718278 < that is |
| 11:04 | <akaroa> | It's not as simple as that Hemebond. There's a lot of politics involved. |
| 11:04 | <om_sleep> | I don't know if there are any formal promises, but all the browser vendors are involved in the HTML working group but not the XHTML2 working group |
| 11:04 | <Hemebond> | Ah politics.... |
| 11:05 | <Hemebond> | How I loath thee. |
| 11:05 | <om_sleep> | and all but MS are already implementing some HTML5 features |
| 11:05 | <othermaciej> | and most have said vaguely negative things about XHTML2 at times |
| 11:05 | <Hemebond> | And yet most haven't finished implementing the specs that are "finished". |
| 11:06 | <annevk> | so 1) XHTML2 doesn't address web applications and 2) it goes against the design principles for HTML |
| 11:06 | <Hemebond> | Design principals? |
| 11:06 | <annevk> | http://www.w3.org/TR/html-design-principles/ |
| 11:06 | <Hemebond> | Cheers. |
| 11:06 | <othermaciej> | depends on what you mean by "finished implementing" and "finished spec" |
| 11:07 | <annevk> | they have been mostly "implicit" so far, but now they have a pointer :) |
| 11:07 | <othermaciej> | the latest specs that have REC status (the most mature status for a W3C spec) are CSS1, HTML4.01 and DOM2 |
| 11:08 | <othermaciej> | (wait, I'm wrong, DOM 3 Core is also REC) |
| 11:08 | <hsivonen> | and HTML 4.01 shouldn't be a REC by today's requirements |
| 11:08 | <othermaciej> | non-IE browsers actually have very good support for DOM1 and DOM2 |
| 11:08 | <othermaciej> | most browsers are pretty good at CSS1 |
| 11:08 | <othermaciej> | HTML4.01 leaves a lot of things unspecified, so it's hard to tell if you really implemented it or not |
| 11:08 | <hsivonen> | (when some CSS1 definitions are updated per CSS2.1) |
| 11:09 | <annevk> | (by today's requirements we wouldn't have RECs, which may indicate we need something else) |
| 11:09 | <hsivonen> | indeed |
| 11:09 | <othermaciej> | I like the IETF's standards track maturity levels |
| 11:09 | <annevk> | maybe that can work |
| 11:10 | <Lachy> | I never understood the IETF maturity levels, they seemed to be quite meaningless |
| 11:11 | <hsivonen> | there's a lot of stuff that one needs to implement on the Web but that hasn't been elevated on the IETF ladder |
| 11:12 | <othermaciej> | the point is that you don't need to reach the top of the IETF ladder to be a successful spec |
| 11:13 | <hsivonen> | also, the IETF hasn't addressed Web realities e.g. the text/* encoding mess |
| 11:13 | <Lachy> | where does the IETF list the maturity levels of their specs? |
| 11:13 | <othermaciej> | ftp://ftp.rfc-editor.org/in-notes/bcp/bcp9.txt |
| 11:14 | <Hemebond> | http://www.w3.org/TR/html-design-principles/ < was this made up by the HTML5 crew or has it always been there? |
| 11:14 | <othermaciej> | Hemebond: it was created by the HTML Working Group |
| 11:15 | <othermaciej> | (edited by me and Anne) |
| 11:15 | <Hemebond> | uhuh |
| 11:16 | <othermaciej> | by IETF process, "Draft Standard" has the interoperable implementation requirement, but still leaves the possibility of changes from further implementation experience if needed |
| 11:16 | <othermaciej> | most things don't reach "Internet Standard" |
| 11:16 | <webben> | othermaciej: Not /all/ the browser vendors are involved in HTML WG. |
| 11:16 | <webben> | (Just the most famous ones.) |
| 11:16 | <othermaciej> | webben: ok, the four highest market share and best-known browser vendors, plus some others |
| 11:17 | <hsivonen> | Hemebond: if you want an older reference, there's the Opera/Mozilla Position Paper from The Workshop |
| 11:17 | hsivonen | looks up the URI |
| 11:17 | <hsivonen> | Hemebond: http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html |
| 11:17 | <Hemebond> | cheers |
| 11:18 | <othermaciej> | (browsers not involved in the WG add up to less than 0.16% market share) |
| 11:18 | <hsivonen> | Hemebond: you probably won't find any official statements about XHTML2 from browser vendors |
| 11:19 | <hsivonen> | but then, you probably won't find any official announcements to implement HTML5, either |
| 11:19 | <Hemebond> | Not really after official statements or anything. Just trying to understand the reason for avoiding XHTML2, that's all. |
| 11:23 | <hsivonen> | Hemebond: some things to consider: 1) XHTML2 involves a discontinuity: there isn't a smooth upgrade path for authors. 2) XHTML2 isn't designed to leverage the existing HTML/XHTML implementations in browsers to the extent XHTML5 is and 3) the payoff of being the first-mover to implement XHTML2 does not appear to be favorable when compared to the cost of the implementation |
| 11:23 | <webben> | Hemebond: Basically, the HTML5 draft provides a lot of additional features that developers can go right out and use today (e.g. Canvas, with JS/VML fakery in IE). XHTML 2 doesn't. So there's a lot more pressure from developers on browser vendors to implement HTML5 features. |
| 11:23 | <webben> | Hemebond: XHTML2 does have useful features that HTML5 doesn't have, but it also breaks a lot of backwards compatibility and isn't designed to degrade gracefully in the one browser that pages absolutely must work in. |
| 11:24 | <Hemebond> | You should paste all this into the FAQ or something... |
| 11:24 | <Hemebond> | FAQ-for-hemebond |
| 11:24 | <Hemebond> | .html |
| 11:24 | <Hemebond> | Thanks for that. |
| 11:24 | <webben> | So moving to XHTML 2 (from a developer perspective) would have costs that generally outweigh the gains. |
| 11:25 | <webben> | Hemebond: There are cases where XHTML 2 as currently drafted might be a better choice than HTML5. e.g. for server-side storage of documents. |
| 11:26 | <akaroa> | webben: how is that? |
| 11:26 | <Hemebond> | akaroa: transform to HTML using server-side scripting |
| 11:26 | <Hemebond> | or XSL |
| 11:26 | <Hemebond> | I've thought of using XHTML as a storage markup. Or even opendoc |
| 11:27 | <webben> | akoroa: Well, just for one example, XHTML 2 allows you to store a machine-friendly version of human-friendly data (as commonly needed for microformats) with the content attribute. |
| 11:27 | <webben> | <span content="PT3M23S">about three minutes</span> |
| 11:29 | <webben> | XHTML 2 also has more extension mechanisms like arbitrary roles and mixing in markup from other (perhaps your own) namespaces. |
| 11:30 | <webben> | Although mixing in namespaces can be done in XHTML 5 too. |
| 11:33 | <webben> | Hemebond: You might also want to look at DocBook and TEI. |
| 11:33 | <Hemebond> | Ah yeah, I meant DocBook above. |
| 11:33 | <Hemebond> | TEI is new to me though. |
| 11:34 | <webben> | http://www.tei-c.org/index.xml |
| 11:34 | <Hemebond> | Just found it. Cheers. |
| 11:34 | <akaroa> | I am still not convinced that there is a use case for XHTML2. HTML5 and XHTML5 should take care of everything right? |
| 11:34 | <webben> | akaroa: "Should" and "will" aren't the same thing. :) |
| 11:35 | <akaroa> | If not, we can still add more features to the spec |
| 11:36 | <webben> | akaroa: Well yes, both drafts could change. |
| 11:36 | <hsivonen> | having more features doesn't necessarily mean better when it comes to deciding the storage format of a back end system |
| 11:36 | <Hemebond> | or front end system |
| 11:36 | <othermaciej> | XHTML2 has decided to focus on being an authoring format |
| 11:37 | <Camaban> | The IBM article that the slashdot link referred to talked about the different philosophies of HTML5 and XHTML2, XHTML2 striving for a purer seperation, and HTML5 striving to be more readily 'practical', is that not a big issue that should be mentioned when talking about the differences between the 2? |
| 11:37 | <Hemebond> | Thanks for the info folks, will have to read up more tomorrow. Night. |
| 11:38 | <othermaciej> | I think HTML5 does a reasonably good job with separation of concerns |
| 11:38 | <othermaciej> | I'd state the main differences as: |
| 11:38 | <othermaciej> | - XHTML2 doesn't really care about compatibility with HTML4, or even XHTML1 very much |
| 11:38 | <Hemebond> | I may as well lurk here and record the discussion.... |
| 11:38 | <Hemebond> | night |
| 11:38 | <webben> | Camaban: That's sort of true, although the WHATWG line has tended to be that things like <I> are just fine when it comes to separating content and presentation. |
| 11:39 | <othermaciej> | - XHTML2 is more concerned with making things really generic by moving semantics and behavior to attributes |
| 11:39 | <webben> | Hemebond: good night :) |
| 11:39 | <Camaban> | some argue the seperation point when HTML5 is wanting to not only define HTML, but the audio/video codecs used, and I believe bits to do with Bluetooth among others? |
| 11:39 | <othermaciej> | - HTML5 is interested in supporting web applications as well as web documents, XHTML2, not so much |
| 11:40 | <Camaban> | not sure where I sit on these issues, it's an area that interests me, and has me stuck on what i think of the XHTML2 Vs HTML5 thing overall |
| 11:40 | <akaroa> | It's not just about whether XHTML2 is good or not, it's about whether it can fit on to the web alongside HTML5 or not. I don't believe it can, and believe that XHTML5 should replace XHTML2 |
| 11:41 | <Camaban> | othermaciej: that's a pretty fundamental difference to HTML as we know it, and I've seen suggestions that if that's the case, should it not be called soemthing else altogether? |
| 11:42 | <othermaciej> | Camaban: what's a pretty fundamental differences? |
| 11:42 | Camaban | shrugs |
| 11:42 | <othermaciej> | er |
| 11:42 | <othermaciej> | "fundamental difference" |
| 11:42 | <webben> | Camaban: Not necessarily. Part of the issue here is that electronic document formats tend to be application formats too in all but name. |
| 11:42 | <Camaban> | othermaciej: supporting web apss as well as web docs |
| 11:42 | <Camaban> | *apps |
| 11:42 | <othermaciej> | Camaban: people write web apps in HTML today |
| 11:43 | <othermaciej> | HTML5, instead of trying to stop them, tries to make this work better |
| 11:43 | <webben> | Camaban: If you look at formats like ODF, the Office formats, PDF they all have support for dynamic forms, scripting, media formats etc |
| 11:43 | <Camaban> | but HTML4/XHTML aren't designed to be 'web app' languages, it's jsut people have worked out how to combine them with javascript and stuff to do it |
| 11:44 | <webben> | Camaban: That's not obvious. |
| 11:44 | <hsivonen> | webben: although in PDF, the dynamism is an awfully bad idea |
| 11:44 | <othermaciej> | that's true, they haven't been designed that way historically (although forms and client-side image maps are clearly app-like features) |
| 11:44 | <webben> | hsivonen: Why is it a worse idea in PDF than any of the others? |
| 11:44 | <othermaciej> | (as is support for scripting and events) |
| 11:45 | <Camaban> | If HTML5, from my limited understanding (hence I generally just lurk round here) is designed to deal with web apps specifically (as well as web pages), that's quite a philisophical difference |
| 11:45 | <othermaciej> | HTML5 tries to pave over the rough edges |
| 11:45 | <webben> | Camaban: HTML has seen shifts in philosophy before. |
| 11:45 | <othermaciej> | well, web apps like gmail, flickr, upcoming, google maps, and so forth are not going away |
| 11:45 | <webben> | Camaban: e.g. the realization that authors needed more control over suggested presentation, without compromising media independence of content. |
| 11:46 | <Camaban> | as I said, I'm unconvinced either way at the moment, I'm trying to resolve some of the for/agaisnt arguements I've seen |
| 11:46 | <othermaciej> | it seems the web is going more in that direction |
| 11:46 | <webben> | (leading to dropping loads of presentational elements and attributes in favour of CSS) |
| 11:46 | <othermaciej> | so your options are either to improve HTML, so that web apps like that fit into the web better |
| 11:46 | <othermaciej> | or you can ignore the issue |
| 11:46 | <othermaciej> | or you can invent a new, wholly different approach for web apps that is not based on HTML at all |
| 11:46 | <hsivonen> | webben: PDF (1.4) is solves the main problem it was designed to solve phenomenally good. the dynamism risks breaking what PDF is phenomenally good at |
| 11:47 | <webben> | hsivonen: Well, that's certainly been the case with HTML too. e.g. scripting and frames etc regularly breaking the usability of the web. |
| 11:47 | <hsivonen> | webben: fortunately, Adobe now has less need to use PDF as a presentation layer for dynamic apps because they have Flex |
| 11:48 | <Camaban> | othermaciej: which is what I've seen some people suggesting, maybe not wholly new, but something not called 'hypertext markup language' |
| 11:48 | <webben> | Like XUL. |
| 11:48 | <hsivonen> | s/good/well/ |
| 11:48 | <webben> | or XAML. |
| 11:49 | <webben> | (or XForms to some extent.) |
| 11:49 | <othermaciej> | or Silverlight |
| 11:49 | <othermaciej> | or Java (for non-markup ways of doing it) |
| 11:49 | <hsivonen> | I wonder if there's a spec for Inkscape's private markup |
| 11:49 | <othermaciej> | or SVG |
| 11:49 | <othermaciej> | or Flex |
| 11:50 | <hsivonen> | webben: the difference is that people want to use HTML for apps. telling them otherwise is not productive |
| 11:51 | <Camaban> | maybe part of the problem is, the people who are pushing the semantic view point, using things for their intended use, rather than just using 'what works', and turning HTML into a web app language doesn't quite fit with some of that |
| 11:51 | <webben> | hsivonen: I don't think people want to use HTML for apps per se. I think people want to write apps that work in popular browsers, and HTML is the cheapest way to do that. |
| 11:51 | <hsivonen> | webben: but twisting PDF from an excellent final-form digital paper into an enterprise app UI layer was a vendor-initiated move to leverage the installed base of a product to gain foothold in a different market |
| 11:51 | <hsivonen> | webben: granted |
| 11:51 | <annevk> | is there any realistic alternative to HTML for doing web apps? |
| 11:51 | <webben> | Flash and (now) Silverlight. |
| 11:51 | <annevk> | if not then I'm not sure if this discussion is productive |
| 11:52 | <othermaciej> | Flash is the only currently realistic alternative |
| 11:52 | <annevk> | I should have said non-proprietary, of course |
| 11:52 | <othermaciej> | Silverlight may get there but does not have the deployment |
| 11:52 | <annevk> | can't have a Web that depends on a single vendor |
| 11:52 | <othermaciej> | Java is widely available but sucks really hard |
| 11:52 | <hsivonen> | webben: but while HTML and Flash make sense as app platforms from the developer POV, what developer would want to choose Adobe Intelligent Document Platform is the UI layer of an app? |
| 11:52 | <othermaciej> | I'm measuring "realistic" solely by feasibility of wide deployment for a web developer |
| 11:52 | <Camaban> | annevk: is HTML the way it *should* be done though? or is this just somehting that's happening because it seems to work? |
| 11:52 | <webben> | hsivonen: I don't know. :) |
| 11:53 | <annevk> | Camaban, I don't really see much issues with using HTML for it |
| 11:53 | <annevk> | along with CSS improvements, API improvements, etc., of course |
| 11:53 | <webben> | annevk: Well, the success of HTML5 web apps is rather dependent on MS actually implementing things. Otherwise you might as well use something like XUL. |
| 11:53 | <othermaciej> | Camaban: I dunno, can you think of a reason it shouldn't be done? |
| 11:53 | <annevk> | webben, no, XUL would be a horrible option |
| 11:54 | <annevk> | everyone, including Moz, is in agreement on that afaict |
| 11:54 | <annevk> | stuff from XUL is useful though and is making its way to HTML5 and CSS |
| 11:54 | <Camaban> | I'm slightly nervous of the idea of an HTML spec including some of the things it's looks like it's going to include, but I don't know if that's because I genuinely htink it's a bad idea, or jsut because it alters my preconceptions of what HTML is and what I 'know', it negates some of my expertise :) |
| 11:55 | <webben> | annevk: And yet there's a community of XUL developers (hence XULRunner etc..) |
| 11:55 | webben | isn't an XUL developer, he should add. |
| 11:55 | <othermaciej> | a lot of the stuff in html5 is all about web documents, not web apps at all, particularly |
| 11:55 | <annevk> | webben, sure, there's a community of people doing Flash too |
| 11:56 | <othermaciej> | some stuff is hybird (<details> could be thought of as an app feature or for an interactive document, <video> certainly makes sense in the context of an interactive multimedia hypertext document) |
| 11:56 | <othermaciej> | some stuff is pretty web-app-oriented (AJAX history support, <canvas>) |
| 11:57 | <akaroa> | webben: I can't think of anything that can done be in Flash or silverlight that can't be done using Web Standards in the future. |
| 11:57 | <othermaciej> | I can understand being nervous about all the new stuff, but change is the one constant in the tech industry, learning to embrace it and adapt is a strength |
| 11:57 | <Camaban> | to be honest, I think some people might be pacified if it was called something like 'multimedia markup lanuage', instead :) |
| 11:57 | <webben> | SQL |
| 11:57 | <othermaciej> | akaroa: "in the future" is a pretty big out |
| 11:58 | <webben> | akaroa: Yes. But it's coping with current browsers that leads people to hack up HTML solutions. |
| 11:58 | <annevk> | Camaban, it was called Web Applications 1.0 at some point |
| 11:58 | <othermaciej> | Camaban: well, for all sorts of compatibility reasons, it has to keep text/html and application/xhtml+xml as the MIME types |
| 11:58 | <annevk> | people preferred HTML5 |
| 11:58 | <othermaciej> | Camaban: and <!DOCTYPE html> as the doctype |
| 11:58 | <webben> | And they'll continue to do so until (unless) a killer app galvanizes end users to change their systems to support something else. |
| 11:58 | <othermaciej> | and use most of the tags historically defined for HTML |
| 11:59 | <akaroa> | othermaciej: I meant with the tools that we have now (CSS, SVG), but improved |
| 11:59 | <othermaciej> | so renaming it would probably be more confusing than helpful |
| 11:59 | <Camaban> | ah, that stuff I wasn't aware of |
| 11:59 | <othermaciej> | akaroa: does "improved" include adding features? |
| 12:00 | <othermaciej> | and in some cases radical performance improvements? |
| 12:01 | <Camaban> | I can see the reasons and desirability for some of the things that HTML5 is doing, I'm just struggling to be convinced that after what was shoved down our throats about XHTML --> XML being the future and all the well defined sepeartion of things etc.... that taking something of a different approach is suddenly meant to be better |
| 12:02 | <akaroa> | othermaciej: yes, adding features I guess. I'm not sure what you mean. I thought you would agree with me :) |
| 12:02 | <webben> | othermaciej: Well, there are a lot of radical performance improvements in stuff like SVG scripting (e.g. the forthcoming tamarin-based improved JS implementation in Moz.) |
| 12:03 | <othermaciej> | akaroa: I'm just saying, it's pretty open-ended to say "you'll be able to do everything in the future" |
| 12:03 | <othermaciej> | I do agree that extending web standards is good |
| 12:03 | <othermaciej> | and improving their implementations |
| 12:03 | <akaroa> | I guess I said it all wrong sorry. |
| 12:03 | <othermaciej> | webben: core JS execution is almost never the bottleneck for scripted SVG animations, in my experience |
| 12:04 | <webben> | othermaciej: What is? |
| 12:04 | <othermaciej> | DOM access, layout, painting |
| 12:04 | <annevk> | yeah, it's not so much JavaScript |
| 12:04 | <webben> | Why should DOM access be intrinsically slower than (say) manipulating Flash objects via actionscript. |
| 12:04 | <othermaciej> | (WebKit is pretty fast on scripted SVG animations, and not because our JS is way better than everyone else's) |
| 12:04 | <othermaciej> | (yet) |
| 12:04 | <webben> | Is that due to something intrinsic or just down to sluggish implementations? |
| 12:05 | <othermaciej> | webben: it doesn't need to be - I'm just saying that Tamarin won't address any of those |
| 12:05 | <webben> | oh okay |
| 12:05 | <othermaciej> | WebKit has a much faster core DOM than Gecko for instance |
| 12:05 | <othermaciej> | as does Opera |
| 12:06 | <Philip`> | JS performance hurts my per-frame lighting calculations for 3D canvas stuff in Opera, so I wouldn't mind that being faster :-) |
| 12:07 | <othermaciej> | this is a fairly good core DOM benchmark |
| 12:07 | <othermaciej> | Philip`: it's certainly worth improving! |
| 12:07 | <othermaciej> | JS performance is one of the top things I personally code on actually |
| 12:07 | <othermaciej> | but it takes a lot of different things to make an excellent web engine |
| 12:08 | <akaroa> | othermaciej: I meant we have a pretty good "web-toolbox" with what is in the (x)html5 spec now + CSS3 SVG etc. |
| 12:08 | <Philip`> | (Firefox does that particular code insanely faster, because it's running as highly optimised code on highly parallel specialised hardware, rather than as JavaScript, which is a better way to solve this problem) |
| 12:09 | <othermaciej> | yeah |
| 12:09 | <othermaciej> | in some cases the best way around JS perf bottlenecks is not to use JS at all |
| 12:09 | <othermaciej> | thus Apple's CSS animation proposal |
| 12:09 | <othermaciej> | btw this is a pretty good core DOM benchmark if anyone would like to test: http://www.hixie.ch/tests/adhoc/perf/dom/artificial/core/001.html |
| 12:46 | <hdh> | /part |
| 13:48 | Philip` | hopes the URI template topic can stay on topic :-) |
| 13:50 | zcorpan | probably should have let that email stay as a draft :| |
| 14:13 | <hsivonen> | RDF and XMLNS show up in the URI template thread... |
| 16:05 | gsnedders | should take a screenshot of all my mailboxes in Mail.app |
| 16:06 | <gsnedders> | but that's hard seeming there's a scrollbar |
| 16:06 | <hsivonen> | 666 messages and 1337 messages? |
| 16:06 | <gsnedders> | no |
| 16:07 | <gsnedders> | (though, according to Last.fm, I stopped listening to Queen after 1337 plays, so I kinda force myself to never listen to any of their stuff) |
| 17:58 | <zcorpan> | Hixie: do you have any idea why the annotation script doesn't work in opera? |
| 17:59 | <zcorpan> | Hixie: it says "Error: (0)." |
| 18:00 | <zcorpan> | which is |
| 18:00 | <zcorpan> | } else if ((x.status != 200) && (x.status != 304)) { |
| 18:00 | <zcorpan> | failure("Error: " + x.statusText + " (" + x.status + ")"); |
| 18:00 | <zcorpan> | ...in doXMLHttpRequest() |
| 20:06 | <krijn> | Damn peer |
| 20:12 | Philip` | sees http://www.bbc.co.uk/iplayer/ is now cross-platform since it uses Flash |
| 20:13 | <webben> | where cross-platform means "more than one platform" presumably |
| 20:14 | <Philip`> | It means "not Windows Media Player" |
| 20:15 | <Philip`> | I can't tell what codec it's using, but it's going over RTMP (unlike e.g. YouTube which is HTTP (I think)) |
| 20:15 | <webben> | Windows Media is probably usable on more platforms than Flash. You can run mplayer on 64-bit *nix I presume. |
| 20:16 | <webben> | but I guess they're probably using a lot of DRM or something |
| 20:16 | <Philip`> | Windows Media Player + Windows Media DRM |
| 20:16 | <Philip`> | which I guess mplayer doesn't handle so well |
| 20:16 | <webben> | probably not |
| 20:18 | <Philip`> | Looks like they're still using Windows Media for the download option (with DRM), and Flash only for streaming (which is hard to save to disk, so it has the same effect as DRM) |
| 20:20 | <Philip`> | I guess they're unlikely to use Ogg :-( |
| 20:21 | <webben> | Could one stream Ogg in a way that would make it "hard" to save? |
| 20:24 | <Philip`> | I guess RTMP mostly works on the basis of being complex and undocumented, so most people won't bother writing tools to download it and to play it back |
| 20:24 | <webben> | Sounds optimistic. |
| 20:24 | <Philip`> | and the 'undocumented' bit wouldn't go down very well in the Ogg community |
| 20:24 | <webben> | Given the existence of projects like Gnash. |
| 20:24 | <webben> | (which depend on ignoring documentation of complex software for their very existence) |
| 20:25 | <Philip`> | http://osflash.org/documentation/rtmp |
| 20:25 | <webben> | heh |
| 20:25 | <Philip`> | with lots of "Fix Me!" labels |
| 20:27 | <Philip`> | It's just a pain to decode these things, and it looks like it's enough of a pain that nobody has added support for "mplayer -dumpstream rtmp://..." yet |
| 21:14 | <Hixie> | i hate how i have to hit _three_ keys to page up and down in a terminal window on mac |
| 21:14 | <Hixie> | (specifically a mac laptop, though even a desktop still requires two keys) |
| 21:16 | <gsnedders> | peh. it depends on the keyboard! |
| 21:17 | <gavin_> | my mac laptop requires two keys (fn+up) |
| 21:17 | <gavin_> | but I had to tweak terminal.app keymappings |
| 21:18 | <Hixie> | yeah i'm tweaking settings too |
| 21:18 | <gsnedders> | I think it's just fn+up here too |
| 21:18 | <gsnedders> | But there again I've little idea what the defaults are |
| 21:20 | <Hixie> | ok i can do it with one hand now |
| 21:20 | <Hixie> | shift-up and shift-down |
| 21:24 | <Hixie> | i don't suppose there's a way to control what double-click selection behaviour is, either? |
| 21:24 | <Hixie> | s/either/too/ |
| 21:24 | <Hixie> | on putty i have it set to just select uri characters, which makes it easy to select uris |
| 21:24 | gavin_ | doesn't know of any |
| 21:25 | <gsnedders> | Hixie: AFAIK no |
| 21:25 | <gavin_> | pre-leopard Cmd+DblCLick was "load link", not it's Cmd+Shift+DblClick |
| 21:25 | <gavin_> | *now |
| 21:25 | <gavin_> | kind of a pain |
| 21:25 | <hsivonen> | indeed |
| 21:26 | <Hixie> | yeah but that selects | characters |
| 21:26 | <Hixie> | so it doesn't work well for me either |
| 21:34 | <hsivonen> | Philip`: did you decrypt the overlap in interleave error with no interleave in sight? |
| 21:41 | <hsivonen> | interleave problem found |
| 21:45 | <Hixie> | hm? |
| 21:51 | <hsivonen> | Hixie: I tried to interleave rdf:RDF with * |
| 22:10 | <roc> | othermaciej: "although I'm not sure if the Microsoft request it was responsive to has been made public" ... those earlier discussions never were made public (as far as I can tell), that's the problem |
| 22:11 | <roc> | This is a powerful reason why the private w3c-css-wg list needs to die. |
| 22:15 | <Hixie> | hsivonen: ah, did it not work? |
| 22:16 | <hsivonen> | Hixie: it didn't since duplicate names in interleave are prohibited and * is a duplicate of everything |
| 22:16 | <hsivonen> | (this is a really annoying feature of RELAX NG) |
| 22:16 | <Hixie> | ah |
| 22:17 | <Hixie> | i don't think we want to allow RDF _anywhere_, btw |
| 22:17 | <Hixie> | <select> <rdf...> would probably not work well |
| 22:17 | <Hixie> | same with various other cases |
| 22:17 | <hsivonen> | Hixie: I thought you said earlies that RDF was OK where metadata elements are OK, i.e. in <head> |
| 22:17 | <Hixie> | i'd recommend just allowing rdf at metadata and block/inline (soon to become "prose") entry points |
| 22:18 | <Hixie> | i may have misunderstood what you meant |
| 22:18 | <hsivonen> | I got rid of the * that was a bug |
| 22:18 | <hsivonen> | I didn't mean * quantifier. I meant the * name class |
| 22:19 | <hsivonen> | currently, I don't allow RDF on the prose level at all |
| 22:19 | <Hixie> | that works for me too |
| 22:19 | <hsivonen> | only in XHTML <head> and SVG <metadata> |
| 22:20 | <Philip`> | hsivonen: I fixed the "Error: Both operands of interleave contain text" by giving up on the RNG conversion and just using XSD |
| 22:20 | <hsivonen> | Philip`: heh |
| 22:21 | <Philip`> | (Now I've imported the XSLT schema and so the XSD->RNG converter just gives up and dies before getting that far) |
| 22:22 | <Philip`> | (Incidentally, I'm probably doing stuff stupidly since I really have no idea about any of this, but at least it seems to be working at the moment) |
| 22:29 | <hsivonen> | Hixie: FYI, http://golem.ph.utexas.edu/~distler/blog/archives/001475.html#c013846 |
| 22:32 | <Hixie> | yeah, we need to figure something out |
| 22:32 | <Hixie> | the parsing issue is the biggest problem, frankly |
| 23:57 | Philip` | sees that at least one of the iPlayer shows has a sign language interpreter overlayed (seemingly with no way to disable it), which is a bit distracting |