| 00:00 | <annevk> | ok |
| 00:00 | <annevk> | introducing colons in HTML is wrong |
| 00:00 | <Philip`> | Why? |
| 00:00 | <Hixie> | he doesn't have a compelling argument |
| 00:00 | <Hixie> | didn't we just go through that? :-) |
| 00:01 | <jgraham__> | Hixie: So you propose that custom be the only namespace prefix and i only work on attributes, or something else? |
| 00:01 | <Hixie> | correct |
| 00:01 | <annevk> | heh |
| 00:01 | <Philip`> | Just trying to either demonstrate the point or have a counterexample demonstrated :-) |
| 00:01 | <annevk> | colon is heavily XML-overloaded |
| 00:01 | <annevk> | no need to bring that complexity to HTML |
| 00:01 | <Hixie> | if we go with namespaces on attributes, and we _don't_ use the colon, it won't map to XML at all well |
| 00:02 | <annevk> | imagine explaining what happens with custom:foobar in a book |
| 00:02 | <Hixie> | and frankly, this is an area where i think namespaced attributes are the technically good solution, in the absence of compatibility and usability |
| 00:02 | <jgraham__> | So what happens if you want to introduce a new element (obviously there are arguments as to why this might be a bad idea) |
| 00:02 | <Hixie> | jgraham__: you use <div> or <span> and give it a class. |
| 00:02 | <Hixie> | jgraham__: new "elements" are the easy problem. it's name-value pairs that are hard. |
| 00:02 | <annevk> | sounds like an argument for <custom:...> |
| 00:03 | <jgraham__> | <div class="canvas">? |
| 00:03 | <annevk> | which is a small step away from xmlns:custom=... |
| 00:03 | <Hixie> | that wouldn't work, e.g. in tables, if you want to associate stuff with <tr> |
| 00:03 | <Hixie> | jgraham__: we're talking about author extensions, not vendor extensions |
| 00:04 | <jgraham__> | With scripting the difference between authors and vendors isn't so large |
| 00:04 | <Hixie> | large enough for me |
| 00:04 | <Hixie> | :-) |
| 00:05 | <jgraham__> | I can't say I particularly disagree, but I won't be surprised if others do |
| 00:05 | <Hixie> | sure |
| 00:06 | <annevk> | having both would work |
| 00:06 | <annevk> | custom elements makes sense for XBL |
| 00:07 | <Hixie> | why? |
| 00:07 | <Hixie> | you mean in the shadow tree? |
| 00:07 | jgraham__ | -> bed |
| 00:07 | <Hixie> | or for binding |
| 00:07 | <Hixie> | for xbl, and for aria for that matter, and libraries, you want to "bind" to the most appropriate html element, so that the document still mostly works without them |
| 00:07 | <annevk> | for the bound element |
| 00:08 | <annevk> | <spaceship> |
| 00:08 | <annevk> | <cart> |
| 00:09 | <annevk> | (i'm not sure why <div class=cart> would be better apart from maybe being slightly faster with styling given cached class names) |
| 00:09 | <Hixie> | well ideally it wouldn't be <div> |
| 00:12 | <Hixie> | man, svg is worthless |
| 00:12 | <Hixie> | wtf are the ua conf requirements for <hkern u="">? |
| 00:12 | <Hixie> | u1 rather |
| 00:12 | <Hixie> | and u2 |
| 00:15 | <annevk> | I've no idea |
| 00:27 | <Hixie> | annevk: yt? |
| 00:27 | <Hixie> | annevk: can you check that the build that got 100/100 did go down to 99/100? |
| 00:28 | <annevk> | no, but i'm passing on the change madea |
| 00:28 | <Hixie> | please do get someone to confirm that the score went down |
| 00:29 | <Hixie> | otherwise there's another bug in the test |
| 00:29 | <annevk> | kk, i guess i'll hear it at some point |
| 00:29 | <Hixie> | thanks |
| 00:30 | <annevk> | not exactly day time in Norway :) |
| 00:30 | <annevk> | / Sweden |
| 00:30 | <Hixie> | yeah |
| 00:38 | <othermaciej> | maybe better here |
| 00:38 | <othermaciej> | Hixie: you have to give the EE glyph a glyph-name="EE" too |
| 00:40 | <Hixie> | oh |
| 00:40 | <Hixie> | so how did opera pass this? |
| 00:40 | <Hixie> | that makes no sense to me |
| 00:40 | <Hixie> | where do i add this glyph-name thing... hmm... |
| 00:40 | <Hixie> | wait, it already has unicode=EE |
| 00:40 | <Hixie> | that's not enough? |
| 00:41 | <Hixie> | oh that's the kerned version? |
| 00:41 | <Hixie> | wait |
| 00:41 | <Hixie> | i'm VERY confused now |
| 00:41 | <heycam> | Hixie, no it needs an explicit name |
| 00:41 | <othermaciej> | the EE glyph spec should be this: e('glyph', { 'unicode': 'EE', 'd': 'M100,0 h100 v-100 h-100 z', 'horiz-adv-x': '1300', 'glyph-name': 'EE'}) |
| 00:41 | <othermaciej> | the kerning pair references it by name now, not by unicode value |
| 00:41 | <othermaciej> | those are separate |
| 00:41 | <othermaciej> | (insanely enough) |
| 00:41 | <Hixie> | so that's the unicode=EE thing?? |
| 00:41 | <Hixie> | what |
| 00:41 | <Hixie> | rather |
| 00:41 | <heycam> | unicode gives the actual characters that map to the glyph |
| 00:41 | <othermaciej> | unicode=EE is the chars the glyph mathces |
| 00:41 | <heycam> | the name could be anything |
| 00:41 | <othermaciej> | but kerning pairs match differently than glyphs |
| 00:42 | <othermaciej> | (insanely enough) |
| 00:42 | <heycam> | glyph-name="theEEGlyph" e.g. |
| 00:42 | <Hixie> | ok fixed |
| 00:42 | <Hixie> | so why is u2=EE wrong, given that unicode=EE is ok? |
| 00:42 | <Hixie> | u2 is defined in terms of unicode, no? |
| 00:42 | <Hixie> | so confused |
| 00:43 | <heycam> | no, u2 is a list of characters (and possible ranges) -- it could be "E,U+1234-U+1300" |
| 00:43 | <heycam> | iirc |
| 00:44 | <heycam> | oh, mistake in the spec |
| 00:44 | <heycam> | s/<number>/<character>/g in the u2="" definition |
| 00:44 | <annevk> | omg |
| 00:44 | <othermaciej> | Hixie: unicode is a string of characters, u2 is a comma-separated list |
| 00:44 | annevk | suggests dropping all SVG tests |
| 00:45 | <Hixie> | ok fuck this, we're not adding svg to html5 |
| 00:46 | <annevk> | lets add svg5 |
| 00:46 | <othermaciej> | svg fonts are one of the more insane parts |
| 01:02 | <Hixie> | gah this custom data thing is dhard |
| 01:02 | <Hixie> | it's actually hard to come up with real examples |
| 01:03 | <Pavlov_> | er, the test is changing after it was published? |
| 01:04 | <Hixie> | to fix bugs that have been found, yes |
| 01:04 | <Pavlov_> | thats kind of confusing my brain |
| 01:04 | <Pavlov_> | but OK |
| 01:05 | <Hixie> | one advantage of not trying to pass the test straight away is that you don't have to worry about such changes :-) |
| 01:05 | <Hixie> | it's just like point releases for software |
| 01:05 | <Hixie> | for security fixes |
| 01:05 | <Hixie> | and stuff |
| 01:05 | <Pavlov_> | except it isn't |
| 01:05 | <tomg> | Acid3 SP1 |
| 01:05 | <Pavlov_> | sure |
| 01:05 | <Pavlov_> | i'd rev the version |
| 01:06 | <Pavlov_> | its just confusing to target one thing and then have it change |
| 01:06 | <Hixie> | the target is the spec |
| 01:06 | <Hixie> | not the test |
| 01:06 | <Hixie> | targetting the test is missing the point |
| 01:07 | <Pavlov_> | so everyone has missed the point? |
| 01:07 | <Hixie> | that's a common problem |
| 01:07 | <Hixie> | the webkit guys haven't been targetting the test, that's why they keep finding the bugs in the test :-) |
| 01:07 | <Pavlov_> | adding an idl file to pass the test isn't targetting the test? |
| 01:07 | <Hixie> | they've been prioritising passing the test |
| 01:08 | <Hixie> | that's not the same as just changing the code to pass the test |
| 01:08 | <Hixie> | (which i don't think anyone would actually do, reddit crowd notwithstanding) |
| 01:12 | <Hixie> | Philip`: ironically, doing getAttributeNS() is exactly what you say you do (and want to have still work in text/html) in your e-mail http://lists.w3.org/Archives/Public/public-html/2008Mar/0156.html |
| 01:24 | <Hixie> | http://wiki.whatwg.org/wiki/CustomData |
| 02:08 | <vlad_> | Hixie: what was the acid3 "fix"? |
| 02:09 | <vlad_> | is there a revision log somewhere with changes? |
| 02:17 | <Nabeel_co> | does Opera fully pass Acid3 now? |
| 02:18 | <vlad_> | they did for about 2 hours today |
| 02:19 | <Nabeel_co> | i thought there were still some rendering issues. |
| 02:19 | <jruderman> | "for about 2 hours"? |
| 02:20 | <G0k> | acid tests should be scored as pH |
| 02:20 | <Nabeel_co> | acid3 was updated?!? |
| 02:21 | <Pavlov_> | again |
| 02:21 | <Nabeel_co> | thats what wiki is saying... |
| 02:53 | <othermaciej> | http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/ |
| 02:58 | <G0k> | so how we doing on acid5? |
| 03:54 | mpt | pre-orders the "Acid5 > Acid2" t-shirt |
| 03:55 | <othermaciej> | haha |
| 04:40 | <othermaciej> | Hixie: I think we have a rendering pass now |
| 04:40 | <othermaciej> | Hixie: but I can't really tell on the animation smoothness |
| 04:40 | <othermaciej> | it looks smooth to me in a release build on my MacBook Pro, but I don't exactly have the best calibrated eyeballs |
| 07:23 | <hsivonen> | Hixie: umm. the colon is bad exactly for the same reasons it was bad for ARIA |
| 07:28 | <Hixie> | i didn't say it was good |
| 07:28 | <Hixie> | i haven't found a good solution yet |
| 07:30 | <hsivonen> | Philip`'s custom data example was in XML or was it even SVG |
| 07:30 | <hsivonen> | the Inkscape cruft and similar happen in SVG trees |
| 07:30 | <hsivonen> | where the legacy considerations are differnt from HTML |
| 07:32 | MikeSmith | wonders if hendry is around |
| 07:44 | <hsivonen> | hmm. Adobe dilutes the Photoshop brand with a Flash app that is less photoshop-like than competing flash apps... |
| 08:21 | <hsivonen> | is it known whether http://www.w3.org/MarkUp/2008/ED-xhtml-role-20080318/ arose of stated use cases? |
| 08:37 | <Hixie> | i wish the people who keep saying acid3 doesn't test useful stuff would be more specific about what's not useful |
| 08:37 | <Hixie> | sigh |
| 08:40 | <othermaciej> | it is edge casey but in many cases that forced us to implement non-edge cases of things too |
| 08:41 | <othermaciej> | I do think testing DOM 2 Events is pretty useful, if way belated |
| 08:41 | <Hixie> | i think i probably overstepped usefulness with the dom traversal tests |
| 08:42 | <Hixie> | but not sure what else to test with it |
| 12:27 | <zcorpan> | custom no-namespace attributes starting with underscore or so would be convenient, i think |
| 12:28 | <zcorpan> | <img class=reflect _height=25 _ropacity=25> |
| 12:30 | <hendry> | MikeSmith: yes? |
| 12:31 | <MikeSmith> | hendry - wanted to ask if you knew much about details of JSR 248 |
| 12:32 | <MikeSmith> | in particular, does it include the location API |
| 12:32 | <MikeSmith> | (I forgot what the JSR number for that is) |
| 12:32 | <hendry> | MikeSmith: JSR179 |
| 12:33 | <hendry> | i don't know the details off hand |
| 12:33 | <MikeSmith> | OK |
| 12:33 | hendry | is sick at home with flu :/ bit useless today |
| 12:33 | <MikeSmith> | The JCP annoyingly only provides specs in PDF form |
| 12:34 | <MikeSmith> | I'll quit being lazy and I'll go ahead and download the PDF and see |
| 12:37 | <MikeSmith> | hmm |
| 12:38 | <MikeSmith> | hendry - it says that JSR 179 is "conditionally mandatory" |
| 12:38 | <MikeSmith> | whatever tf that means |
| 12:39 | <MikeSmith> | [[ |
| 12:39 | <MikeSmith> | JSR 179 MUST be implemented if the target device meets at least one of the following |
| 12:39 | <MikeSmith> | conditions: |
| 12:39 | <MikeSmith> | • The device has a GPS receiver that is able to deliver the geographical coordinates |
| 12:39 | <MikeSmith> | within the device |
| 12:39 | <MikeSmith> | • The device supports a location method that is capable of delivering the geographical |
| 12:39 | <MikeSmith> | coordinates and is used to deliver the coordinates to downloadable applications (in |
| 12:39 | <MikeSmith> | Java ME or other runtime platforms) |
| 12:39 | <MikeSmith> | • The device supports an accessory device that can be used to obtain geographical |
| 12:39 | <MikeSmith> | coordinates, and which is used to deliver the location to downloadable applications |
| 12:39 | <MikeSmith> | (in Java ME or other runtime platforms) |
| 12:39 | <MikeSmith> | ]] |
| 12:39 | <MikeSmith> | oops |
| 12:39 | <MikeSmith> | sorry |
| 12:39 | <MikeSmith> | that was a bit more than I intended to paste.. |
| 12:41 | <MikeSmith> | so seems, in a nutshell, if any device supports has some kind of location-sensing capability and it claims to comply with JSR 248, then it must support JSR 179 |
| 12:46 | <MikeSmith> | and my understanding is that JSR 248 is supposed to be sort of the baseline/"lowest common denominator" set of JSRs that Java ME environments should support |
| 13:29 | <takkaria> | hmm. I wonder if the correct way to mark up the term "a priori" is with <i> |
| 13:44 | <Philip`> | takkaria: <span lang="la">a priori</a> <style>[lang="la"]{font-style:italic}</style> |
| 13:45 | <BenMillard> | Philip`, that doesn't degrade as nicely as <i lang> would when author CSS is not used |
| 13:46 | <BenMillard> | both seem fine to me |
| 13:47 | <takkaria> | Philip`: hm, interesting |
| 13:47 | <takkaria> | I should have thought of lang |
| 13:47 | <hsivonen> | Philip`: would you expect a proper Latin pronunciation or an English approximation? |
| 13:49 | <Philip`> | BenMillard: But the italic styling is just a presentational effect that is conventional in high-res visual contexts with suitable text rendering, and isn't universally applicable, whereas any UA could process lang=la in a suitable way for its particular medium |
| 13:50 | <hsivonen> | Philip`: my point is: is proper Latin pronunciation really the suitable thing for a user whose listening comprehension is calibrated for English? |
| 13:51 | <BenMillard> | Philip`, <i> does not preclude UAs doing their own thing: user stylesheets can override the italic with something more approrpriate, although I've no idea what that would be |
| 13:52 | <BenMillard> | also, for the languages where <i> is conventional, you don't need "high-res visual contexts which suitable text rendering". for example, Lynx running on a terminal will apply colour rather than italicising |
| 13:52 | <BenMillard> | s/which/with |
| 13:53 | <Philip`> | BenMillard: <i> doesn't allow UAs to distinguish the Latin italics from the e.g. ship name italics |
| 13:53 | <Philip`> | ...though I suppose you should use <i lang="la"> then |
| 13:54 | <BenMillard> | yes, my suggestion was <i lang> rather than <span lang>. I could have made that clearer :) |
| 13:54 | <Philip`> | hsivonen: Hmm, I suppose that's a problem |
| 13:55 | <Philip`> | Maybe it should be lang="en-la" or something |
| 13:55 | <Philip`> | (though that's probably incorrect usage) |
| 13:55 | <BenMillard> | English is a melting pot of lots of languages; I think Latin phrases like which have been in use as long as they have are basically English now |
| 13:56 | <Philip`> | BenMillard: There are lots of words that nobody even notices are based on Latin, but there are still words and phrases that people tend to write in italics to indicate that they're foreign |
| 13:56 | <BenMillard> | indeed, there are basically 3 categories as I understand it: |
| 13:57 | <BenMillard> | 1. English words |
| 13:57 | <BenMillard> | 2. words from other languages commonly used in English and pronounced as English (such as these Latin phrases) |
| 13:57 | <BenMillard> | 3. foreign words |
| 13:57 | <BenMillard> | 2. could use <i>foo</i> |
| 13:58 | <BenMillard> | 3. could use <i lang>foo</i>? |
| 13:58 | <takkaria> | the italicising of a priori (et al) seem to me to be equivalent to using scare quotes round a word |
| 13:58 | <takkaria> | "Our 'a priori' knowledge of the world..." vs. "Our /a priori/ knowledge of the world..." |
| 13:59 | <takkaria> | not necessarily an indication of the source language |
| 14:00 | <Philip`> | I think italicising a priori makes it much easier to read, because otherwise I start to read as if it was talking about a priory and then have to backtrack and switch to a pseudo-Latin mode and carry on |
| 14:00 | <Philip`> | s/italicising/visually distinguishing in some way/ |
| 14:01 | <Philip`> | It would be much easier if England hadn't got itself invaded so much |
| 14:05 | <BenMillard> | we've avoided that for nearly 1,000 years, IIRC. the source of our diversity is a very long history |
| 14:54 | <Camaban> | Philip`: we did our fair share of invading back :) |
| 14:58 | <BenMillard> | camaban, yeah and brought even more new words back with us :P |
| 14:59 | <Camaban> | and curry |
| 14:59 | <Camaban> | mmmm |
| 15:35 | Philip` | sees http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/folder_expand/global-custom pointing to http://www.quirksmode.org/blog/archives/2007/04/html_5.html pointing to http://www.alistapart.com/articles/scripttriggers/ suggesting to use a custom DTD so that custom attributes are valid, which doesn't sound like a good idea |
| 15:36 | <Philip`> | Also that last page's custom attributes seem to conflict with WF2, which doesn't sound good either |
| 15:56 | <Philip`> | By the way, why does A List Apart say "Was it good for you, too?" at the end of the articles? That really doesn't fit with the style of the site |
| 17:10 | <zcorpan> | html5 parsing of <noframes></noframes><frameset>... seems to be incompatible with real pages |
| 17:27 | <hendry> | MikeSmith: You're right there |
| 18:50 | <mitsuhiko> | Hixie: i think the problem is that Acid3 divided web developers and useres into ie|firefox and webkit|opera ;) now the mozilla guys have to come up with explanations why they fail the test, and obviously the first one is that acid3 doesn't matter |
| 18:51 | <mitsuhiko> | beside that are they correct. acid3 doesn't matter *as long* as firefox and IE are failing it as they have the lion share of the browser market currently |
| 18:56 | <Philip`> | Acid3 only matters if people think it matters - otherwise it's just like any other list of browser bugs that might hang around for years with nobody caring enough to fix them |
| 18:57 | <annevk> | same goes for standards in general |
| 19:01 | <othermaciej> | major browser vendors saying it doesn't matter does create something of a self-fulfilling prophecy perhaps |
| 19:01 | <othermaciej> | still, I think Acid2 ended up mattering, despite being initially downplayed in some quarters |
| 19:19 | <Hixie> | zcorpan_: don't want the custom attributes to be _too_ convenient... just more convenient than abusing html and clashing with future extensions |
| 19:20 | <BenMillard> | oh, that sounds like the tail end of a conversation I wish I'd been here for. *runs off to the IRC logs* |
| 19:22 | <annevk> | there needs to be enough encouragement for people to use them |
| 19:22 | <annevk> | custom attributes are causing pain for Web Forms 2 already |
| 19:22 | <annevk> | (I didn't see what zcorpan_ said btw) |
| 19:24 | <Hixie> | he said to use _foo="" |
| 19:24 | <annevk> | wfm, but I wonder if authors would do that correctly |
| 19:25 | <annevk> | maybe x- |
| 19:27 | <annevk> | nah, dismiss that |
| 19:27 | <annevk> | x is experimental, not custom |
| 19:27 | <BenMillard> | c-foo? |
| 19:28 | <BenMillard> | less characters the better |
| 19:28 | <BenMillard> | nearer to other HTML attributes the better |
| 19:28 | <Hixie> | custom attribute technique |
| 19:28 | <Hixie> | cat- |
| 19:29 | <Hixie> | i was also thinking pua-, custom-, private- |
| 19:29 | <Hixie> | but all this is moot when you consider that the use case Philip` pointd out is already abuse |
| 19:30 | <Hixie> | class="ropacity25" |
| 19:30 | <BenMillard> | I remember chatting about this briefly in a taxi with hsivonen during the HTMLWG F2F in Boston 2007 |
| 19:31 | BenMillard | is still reading through the log for today |
| 19:36 | <BenMillard> | the thing I'm most interested by is removing data from the title attribute and putting it somewhere out of the way |
| 19:37 | <BenMillard> | Microformats put various types of data in title which are not human-readable |
| 19:38 | <annevk> | fwiw, if there's a lot of deployed content that'd be hard to change |
| 19:43 | <BenMillard> | annevk, the Microformats authors generally seem responsive to developments in the formats. so perhaps not impossible |
| 19:44 | <BenMillard> | I mean, authors who use Microformats |
| 19:53 | <annevk> | k |
| 19:53 | <hsivonen> | _foo is ugly but WFM |
| 19:54 | <annevk> | -x apparently does not work for XML |
| 19:54 | <hsivonen> | I think human-unfriendly data in title is an antipattern |
| 19:55 | <hsivonen> | Hixie: Dojo has lots of custom attribute use cases, though I don't expect you to like them :-) |
| 19:55 | <Hixie> | yeah, i know |
| 19:56 | <Hixie> | custom-foo= or private-foo= seem like the most plausible solutions |
| 19:57 | <hsivonen> | "custom-" and "private-" are longish |
| 19:58 | <Hixie> | yes |
| 19:59 | <mitsuhiko> | annevk: why not :? |
| 20:00 | <Lachy> | the problem with custom- and private- prefixes will be getting authors to use them, which will be difficult given their length |
| 20:01 | <Hixie> | the problem with _foo is that it's ugly and doesn't convey that it's not really ok |
| 20:01 | <mitsuhiko> | (as a python programmer _foo means don't touch it) |
| 20:02 | <hsivonen> | I think conveying that you don't think custom attrs are OK by making them suck is not a good policy |
| 20:02 | <Hixie> | why not? |
| 20:02 | <Hixie> | how else would we do it? |
| 20:02 | <Hixie> | and it's not like custom- and private- suck _that_ much |
| 20:02 | <Hixie> | no more than _, imho |
| 20:02 | <BenMillard> | they are readable, as a pro |
| 20:03 | <hsivonen> | Hixie: what's the harm with custom attributes vs. loading script data over, say, XHR? |
| 20:03 | <Hixie> | hsivonen: nothing, that's a valid use. the problem is when people start using them for things that should be in html markup |
| 20:03 | <annevk> | mitsuhiko, mostly because it clashes with XML |
| 20:03 | <Hixie> | e.g. <div class=progress _min=0 _current=5 _max=100></div> |
| 20:03 | <annevk> | mitsuhiko, just like starting with - |
| 20:03 | <hsivonen> | <html custom-ua-compatible='...'> |
| 20:04 | <Hixie> | ? |
| 20:04 | <annevk> | something IE could do to sneak past validators |
| 20:04 | <mitsuhiko> | annevk: xml doesn't disallow : per se, but xmlns aware parsers would probably irk |
| 20:04 | <annevk> | mitsuhiko, oh, that may be true, but the world is based on namespace aware parsers :) |
| 20:05 | <mitsuhiko> | touche ;) |
| 20:05 | <mitsuhiko> | annevk: i did too much wordpress lately |
| 20:05 | <mitsuhiko> | they are parsing with regular expressions.. |
| 20:05 | <Hixie> | and yes, letting vendors invent new values that end up passing through here is another problem |
| 20:06 | <hsivonen> | hmm. I think "Required Child Elements" in ARIA means "Only kind of permitted child elements" |
| 20:07 | <BenMillard> | annevk, what's the difference between experimental and custom? |
| 20:07 | <annevk> | experimental is not conforming |
| 20:08 | <BenMillard> | ah, thanks |
| 20:08 | <hsivonen> | Experimental is deployed by multiple parties forever. Custom is deployed by a single party. |
| 20:08 | <annevk> | true, experimental is generally a bad idea |
| 20:08 | <annevk> | imagine having to standardize on <x-canvas> |
| 20:09 | <BenMillard> | experimental features which prove useful enough are then standardised as standard features, without experimental syntax, and the people who participated in the experiment update their content? |
| 20:10 | <Hixie> | haha |
| 20:10 | <hsivonen> | is there existing content with treegrids built out of SVG? |
| 20:10 | <Hixie> | BenMillard: precisely. except for the bit where the name changes. :-) |
| 20:10 | <Hixie> | actually that's not really fair |
| 20:10 | <Hixie> | css has good experience getting names changed after the experimental phase |
| 20:11 | <hsivonen> | will be fun to see if MS actually changes any NS URIs in OOXML... |
| 20:11 | <annevk> | wow: http://www.paciellogroup.com/blog/?p=50 |
| 20:11 | <hsivonen> | the reason why I ask about treegrids is that I'm considering sending a comment about optimizing grid and treegrid for <table> and making them <table>-only |
| 20:14 | <BenMillard> | hixie, CSS property names and values were examples I was going to give |
| 20:15 | <BenMillard> | annevk, what do you find surprising about that piece? |
| 20:15 | <jgraham__> | In Steve's blog post, what is a line? |
| 20:15 | <annevk> | with CSS it sort of works because of the "error handling" is vastly different |
| 20:15 | <annevk> | BenMillard, the way he tries to bash Hixie |
| 20:16 | <annevk> | without really good reason, because the case Hixie was talking about doesn't work well by default and the Jaws people actually acted on bug reports done by Hixie |
| 20:16 | <jgraham__> | Because if I understand correctly, Jaws sounds, naively, broken by design |
| 20:17 | <jgraham__> | (as in, my naive reaction to its behaviour is "that's broken") |
| 20:18 | <BenMillard> | yes, I get the feeling they have such a hard time squeezing any amount of accessibility from all the desktop apps and formats their customers what to use that basic "fit and polish" gets a bit neglected |
| 20:19 | <BenMillard> | s/what/want |
| 20:19 | jgraham__ | seriously hopes the open source screen readers shake up the market |
| 20:20 | <BenMillard> | time for dinner, bye all |
| 20:20 | <Hixie> | hm, henri once suggested just using script-private="..." |
| 20:30 | <hsivonen> | hmm. does VoiceOver have a command "read from this point onwards until I press a key"? |
| 20:41 | <Philip`> | Lachy: The only people who will use a specified custom-attribute syntax will be people who care about conformance, because people who don't care can just use anything they like and it'll work just as well; and for the people who do care, they'll do the easiest thing the conformance checker lets them get away with, and 'custom-foo' is easier than adding attributes through script or writing a custom DTD |
| 20:45 | <Lachy> | Philip`, it's the ones that don't care about validation that are the problem. |
| 20:46 | <Philip`> | Lachy: There's nothing we can do to those people |
| 20:46 | <Philip`> | (unless they use libraries written by people who do care) |
| 20:47 | <Philip`> | We're not adding any feature, we're just changing conformance, so people who don't care about conformance won't be affected at all |
| 20:53 | <Lachy> | Philip`, one of the problems that custom attributes is attempting to solve is reducing the possibility of clashes, especially with future standards. |
| 20:55 | <zcorpan_> | css has solved that neatly |
| 20:55 | <zcorpan_> | (without namespace indirection) |
| 20:55 | <Lachy> | finding a solution that is as easy or easier to use than not using it increases the chance that people who don't care so much about validation will use it |
| 20:56 | <Philip`> | zcorpan_: Custom extensions to CSS are useless because they don't do anything at all, which is why nobody does that and there's no problem |
| 20:56 | <zcorpan_> | Philip`: there's UA-specific extensions |
| 20:58 | <Philip`> | zcorpan_: UA-specific extensions are done by people who know what they're doing and tend to follow guidelines, which is totally different from custom attributes in HTML content |
| 20:59 | <zcorpan_> | Philip`: yes, but the same syntax can be used for html nevertheless |
| 21:01 | <othermaciej> | I don't know if UA-specific extensions are always done by people who know what they are doing |
| 21:01 | <othermaciej> | I mean, look at <canvas> |
| 21:01 | <othermaciej> | it would be nice if HTML had a good design for how to do experimental UA-specific extensions |
| 21:01 | <othermaciej> | without overconstraining future standards |
| 21:03 | <zcorpan_> | but there's no guideline for how to extend html |
| 21:09 | <Hixie> | ok so i've been thinking about the author custom data thing |
| 21:09 | <Hixie> | it's usually for including data about an element that html has no way to mark up |
| 21:09 | <Hixie> | so why not introduce a prefix "data-" |
| 21:10 | <Hixie> | as in, <li class="drink" data-alcohol="0.5" data-color="blue"> Antikka </li> |
| 21:10 | <Hixie> | we can also add HTMLElement.data as an object that can be indexed to obtain the attributes' values |
| 21:10 | <Hixie> | as in, li.data.alcohol, li.data.blue |
| 21:11 | <zcorpan_> | doesn't it clash with <object data>? |
| 21:11 | <Hixie> | this would not be available on HTMLObjectElement (<object>) |
| 21:11 | <hober> | s/blue/color/ |
| 21:11 | <Hixie> | hober: right, sorry |
| 21:11 | <Hixie> | zcorpan_: yeah, wouldn't be available on <object> |
| 21:12 | <zcorpan_> | Hixie: that would be bad |
| 21:12 | <zcorpan_> | i like the idea though |
| 21:12 | <zcorpan_> | just come up with a name that doesn't clash with existing attributes :) |
| 21:12 | <Philip`> | 'datum' |
| 21:13 | Philip` | hates that word |
| 21:15 | <Philip`> | It seems slightly irritating to tell people to use data-foo and .data.foo but then tell them to actually use getAttribute('data-foo') for the next half a decade until browser support has propagated through the market sufficiently |
| 21:15 | <zcorpan_> | _foo and getAttribute('_foo') would work for me ;) |
| 21:15 | <hober> | what does this do in IE? http://tinyurl.com/2nn5ll |
| 21:15 | <zcorpan_> | or -foo or whatever prefix |
| 21:15 | <Hixie> | Philip`: well, we just don't mention .data for now |
| 21:16 | <zcorpan_> | hober: $ can't be used in xml |
| 21:16 | <hober> | figures :( |
| 21:16 | <Philip`> | and .data.foo isn't much easier to type, and there are lots more special cases to remember (<div data-var=...>) or to catch you out because you actually won't remember |
| 21:17 | <Philip`> | (<div data-mean=... data-var=...> wouldn't be implausible) |
| 21:17 | <Philip`> | ((or <td> or whatever)) |
| 21:18 | <Philip`> | Oh, you could just use .data['var'] all the time instead, to avoid the special cases |
| 21:18 | <Hixie> | yeah |
| 21:20 | <Hixie> | ok well i'm gonna go to work, but unless someone finds a better solution, i'm going with data-*="" and .data[*] (the latter not being available on <object> for historical reasons) |
| 21:20 | <Hixie> | bbiab |
| 21:37 | <jgraham> | Incidentally, I don't really consider "animation without script" to be a problem description (specifically it needs justification as to why lack of script is a desirable property) |
| 21:42 | <hsivonen> | isn't animation without script now in Acid3, so extending it to HTML would make the code needed to pass Acid3 more useful |
| 21:44 | <othermaciej> | I think CSS animation is a better way to bring animations without script to HTML |
| 21:44 | <othermaciej> | and that does not share all *that* much of the code with SVG (though you can share some of the animation controller back end) |
| 21:44 | <Lachy> | hsivonen, what animation in acid3 is done without script? |
| 21:44 | <othermaciej> | Lachy: the SVG Animation tests |
| 21:44 | <Lachy> | oh, right |
| 21:44 | <othermaciej> | (using SVG's SMIL-like animation) |
| 21:45 | <jgraham> | hsivonen: That might be tru but it's still not a valid use case for animtion without script |
| 21:46 | <othermaciej> | I could imagine a "multimedia" style piece of animated content that was more document-like than app-like |
| 21:46 | <hsivonen> | jgraham: is wanting to do Flash-like things without plug-ins more valid? |
| 21:46 | <othermaciej> | I could see reasons to want such a thing to want to work without script |
| 21:46 | <othermaciej> | Flash-like is of course not very aligned with "without script" |
| 21:46 | <jgraham> | hsivonen: you still need to justify "without script" |
| 21:47 | <jgraham> | (the common W3C justification is that it's easier to author) |
| 21:47 | <hsivonen> | jgraham: I take it that "without Flash" is more justified :-) |
| 21:47 | <jgraham> | (but I'm not sure I believe that) |
| 21:47 | <jgraham> | hsivonen: without Flash is fine by me :) |
| 21:55 | <roc> | sorry for joining late, but did anyone mention that doing animation without script is useful because it lets the user agent control the frame rate and synchronize all running animations at each frame? |
| 21:56 | <othermaciej> | animation without script is indeed a case where performance and accuracy can be improved with an approach that isn't all script |
| 21:56 | <othermaciej> | (doesn't necessarily need to be "without script", for example, this is still possible if script defines an animation and then fires it to be driven by the UA) |
| 21:57 | <roc> | sure |
| 21:57 | <othermaciej> | (but I kinda like the CSS declarative model at least for transitions) |
| 21:57 | <roc> | so do I |
| 21:58 | <othermaciej> | though you can't always trigger the CSS state change without script for all useful cases |
| 21:58 | <othermaciej> | but often it only takes a wee little bit of script, and cases like :hover work with no script at all |
| 21:59 | <othermaciej> | an equivalent of HTML <button> that can toggle in a way that CSS selectors can see would help many other likely cases be totally script-free |
| 22:00 | <roc> | :active doesn't do it? |
| 22:00 | <Philip`> | "cases like :hover" - isn't that the only case where you can get anything dynamic? |
| 22:02 | <othermaciej> | roc: toggles like a checkbox I mean |
| 22:02 | <annevk> | .data sounds like it will clash with existing stuff |
| 22:02 | <othermaciej> | not toggles while the mouse is down |
| 22:02 | <roc> | ah |
| 22:03 | <othermaciej> | <input type="checkbox"> can't have content |
| 22:03 | <othermaciej> | so you can't just use that |
| 22:13 | <annevk> | Hixie, the Acid3 fix did make us go to 99% |
| 22:16 | heycam | notes that from the acid test correction it looks like i hate svg, which clearly isn't true :) |
| 22:26 | <othermaciej> | heycam: I have to give you credit for impressive work with test 79 btw |
| 22:26 | <othermaciej> | for WebKit at least it was by far the hardest test to pass |
| 22:26 | <othermaciej> | (I say that despite the couple of bugs the test had originally) |
| 22:29 | <heycam> | othermaciej, thanks. though it does stand out somewhat like a sore thumb in amongst the rest of the tests (which are succinct). |
| 22:30 | <othermaciej> | heycam: it's fairly succinct, just very tricky |
| 22:30 | <gsnedders> | suggestions for better wording for <http://stuff.gsnedders.com/http-parsing.html#anchor5>; are welcome |
| 22:30 | <othermaciej> | you know, my brain is so warped, that whenever I see the number 5 now I wonder "what spec is that?" |
| 22:30 | <heycam> | tricksy svg fontses... |
| 22:30 | <othermaciej> | so I was sitting there thinking, "what could Anchor5 possibly be?" |
| 22:31 | <gsnedders> | othermaciej: you know what's awesome? At school I'm in Secondary 5 :D |
| 22:31 | <hsivonen> | implementing @font-face cross-platform seems impressive Opera is indeed passing Acid3 on multiple platforms |
| 22:31 | <gsnedders> | othermaciej: next year of school will suck. Secondary 6 :( |
| 22:31 | <hsivonen> | does WebKit implement @font-face using CoreGraphics or MS APIs on Windows? |
| 22:32 | <othermaciej> | CG |
| 22:32 | <othermaciej> | although, we are also implementing a GDI text path and would like it to support all text features |
| 22:32 | hsivonen | finds it weird that people actually want GDI antialiasing |
| 22:33 | <othermaciej> | has Opera been retested against the latest Acid test yet? |
| 22:33 | <othermaciej> | hsivonen: you're not the only one :-) |
| 22:33 | <annevk> | yes, see my remark above |
| 22:33 | <gsnedders> | GDI. Eww. |
| 22:33 | <othermaciej> | oh I see |
| 22:34 | <othermaciej> | hsivonen: to my eyes CG's text looks way better than ClearType rendering, but clearly not everyone agrees |
| 22:34 | <othermaciej> | hsivonen: I should be clear and say we want to support it in the engine, that doesn't necessarily mean it will ever be an end-user UI option |
| 22:34 | <roc> | I would have thought implementing SMIL was more work than SVG fonts |
| 22:34 | <annevk> | WebKit hasn't exactly implemented SMIL |
| 22:34 | <othermaciej> | we didn't need to add as much to our partial SMIL implementation as we did to our partial SVG font implementation |
| 22:35 | <othermaciej> | (partly because the test was less rigorous) |
| 22:35 | <roc> | don't tell me you implemented just enough to pass the test! |
| 22:35 | <othermaciej> | we turned on what we had ifdef'd out |
| 22:35 | <hsivonen> | I don't like GC's "Flat Panel" anti-aliasing, so I run in the CRT anti-aliasing mode on a flat panel |
| 22:35 | <othermaciej> | added enough to pass the test |
| 22:35 | <othermaciej> | and will probably add more |
| 22:35 | <hsivonen> | s/GC/CG/ |
| 22:35 | <gsnedders> | hsivonen: I've used the flat panel AA for years, and never had any compliants |
| 22:36 | <gsnedders> | it's so subjective, though |
| 22:36 | <roc> | hmm |
| 22:36 | <othermaciej> | I don't think our svg text implementation is 100% complete either but it is still useful |
| 22:36 | <annevk> | from the official test suite WebKit passes exactly 1 test per some blog |
| 22:36 | <annevk> | SMIL test suite ^^ |
| 22:37 | <annevk> | (well, SVG Animation) |
| 22:37 | <roc> | I sure hope you're going to round out to some reasonable functionality subset before you shipa release |
| 22:37 | Philip` | imagines sub-pixel font rendering depends a lot on the physical size of a pixel and how far you are from the screen |
| 22:37 | <othermaciej> | until recently I think we may have passed close to 0 of SVG's official text tests |
| 22:37 | <gsnedders> | (does anyone have any suggestions about the wording in the above http-parsing draft?) |
| 22:37 | <othermaciej> | because every test includes at least one weird thing |
| 22:37 | <othermaciej> | now I think we arguably pass a fair number |
| 22:37 | <gsnedders> | Philip`: and also your eye-sight |
| 22:38 | <othermaciej> | we'd still fail anything that did vertical text layout and had custom per-glyph vertical advances |
| 22:38 | <othermaciej> | roc: me too - we had it off before in part because it was not yet a useful subset |
| 22:38 | <othermaciej> | (and in part because we were unsure about stability) |
| 22:38 | <Philip`> | gsnedders: Oh, I forgot about that |
| 22:38 | <gsnedders> | Philip`: which is why it is really subjective |
| 22:38 | <roc> | well I hope the drive for acid3 hasn't overridden your better judgement |
| 22:38 | <Philip`> | gsnedders: Not if you think your subjects are just objects |
| 22:39 | <gsnedders> | Philip`: I'm a person, not an object! |
| 22:39 | <Philip`> | gsnedders: A person is just a object :-p |
| 22:39 | <gsnedders> | Philip`: class Person? |
| 22:39 | <Philip`> | s//n/ |
| 22:39 | <othermaciej> | roc: our normal judgment would be to allow partial features to be on by default on trunk, as long as they are being maintained and improved |
| 22:39 | <othermaciej> | (and aren't huge stability/security risks) |
| 22:40 | <othermaciej> | also when we turned it on we thought we'd have to patch it more to pass the test |
| 22:40 | <Hixie> | annevk: k thanks |
| 22:40 | <gsnedders> | Philip`: class gsnedders(Person): |
| 22:40 | <roc> | ok |
| 22:40 | <othermaciej> | we do sometimes turn things off on a branch if they seem to be a subset that will "poison the well" for the feature |
| 22:41 | <othermaciej> | (kind of like Firefox 3 turning off cross-site XHR, though I'm not sure I entirely agree with the reasoning on turning it off in that case) |
| 22:42 | <roc> | we agonized over several such decisions |
| 22:42 | hsivonen | hopes PDF has already exposed all the security holes there are to expose with untrusted TrueType hints |
| 22:42 | <roc> | that's not clear |
| 22:42 | <roc> | the Web is a more effective attack vector than Word docs or PDF docs |
| 22:42 | <roc> | we're worried about it |
| 22:43 | <othermaciej> | Apple's security guys agreed that @font-face doesn't create new exposure that PDF didn't already (since we have native PDF support, at least on Mac) |
| 22:43 | <Philip`> | I guess Acrobat has its own TTF code and doesn't rely on other libraries? |
| 22:43 | <Philip`> | (so it would still be a security risk if a browser did rely on libraries that weren't already used for PDF) |
| 22:43 | <roc> | Freetype and GDI are definitely exposed via PDF and Word respectively |
| 22:44 | <roc> | but that may not be enough to satisfy |
| 22:44 | <othermaciej> | GDI is also exposed via IE's @font-face |
| 22:44 | <othermaciej> | (EOT only, but I assume that can include the hints) |
| 22:45 | <Philip`> | Exposure doesn't mean there aren't lots of significant flaws, so I suppose it doesn't help all that much |
| 22:45 | <roc> | othermaciej: yes, good point |
| 22:45 | <othermaciej> | what matters is whether it has been meaningfully analyzed and tested, and whether the responsible party, if a third party, is committed to fixing vulnerabilities in a timely manner |
| 22:47 | <Philip`> | What matters more is whether the programmers were any good at security or not :-) |
| 22:50 | <roc> | well that rules out GDI |
| 22:50 | Philip` | doesn't have great faith in popular software or their programmers, after finding AWStats blatantly doing 'eval("some_function_$some_direct_user_input_string")' which allowed arbitrary code execution |
| 22:51 | <hsivonen> | FreeType has the advantage of not running font-provided hints |
| 22:51 | <Philip`> | hsivonen: Depends on how it's compiled |
| 22:51 | <hsivonen> | (under normal U.S.-compliant configurations) |
| 22:52 | Philip` | wonders how many people use normal U.S.-compliant configurations |
| 22:52 | <roc> | haven't those patents expired yet? |
| 22:52 | <Philip`> | http://freetype.sourceforge.net/patents.html says 1989 and 1992 |
| 22:55 | <hsivonen> | patents should require the "apparatus" to be something more novel than a Turing-complete computer |
| 22:55 | <Hixie> | woah, the whatwg "html5" page is back up to 3rd spot on google |
| 22:55 | <Hixie> | sweet |
| 22:55 | <Hixie> | i didn't even have to go bribe anyone in the web search team |
| 22:55 | <annevk> | :p |
| 22:55 | <hsivonen> | Hixie: depends on local version, it seems |
| 22:55 | <annevk> | it's 1st for me btw |
| 22:55 | <hsivonen> | whatwg.org is today #1 in .fi |
| 22:55 | <Hixie> | cool |
| 22:55 | Philip` | sees that Gentoo compiles Freetype with the patenting hinting, unless you're building a distributable binary package |
| 22:56 | <Hixie> | may be just personalised results |
| 22:56 | <roc> | It's #1 in .au |
| 22:56 | <Philip`> | hsivonen: Including if you don't have Google-cookies? |
| 22:56 | <annevk> | hmm, as in, Google thinks I prefer WHATWG over W3C? :D |
| 22:56 | <othermaciej> | Hixie: they're probably just counting on you to inject their evil bloatware pet features directly into the HTML5 spec |
| 22:56 | <hsivonen> | Philip`: I thought I had the tinfoil hat on |
| 22:56 | <Philip`> | It's first and third for me in different browsers |
| 22:56 | <Hixie> | oh wow. whatwg is first in the normal results |
| 22:56 | <Hixie> | but w3c is first when i'm logged in |
| 22:56 | <Hixie> | hahaha |
| 22:56 | <Hixie> | google thinks i prefer the w3c to the whatwg |
| 22:56 | <Hixie> | that is funny as hell |
| 22:56 | <othermaciej> | google personalization fails |
| 22:57 | <annevk> | lol |
| 22:57 | <Philip`> | Maybe it knows you've already got bookmarks to the WHATWG and so you don't need even more ways to access it |
| 22:57 | <Hixie> | haha |
| 23:00 | <hsivonen> | hmm. google.fi has become less country-biased on my ego search |
| 23:00 | Philip` | imagines SEO people aren't so happy about personalised results, because it's kind of hard to sell definite results |
| 23:00 | <hsivonen> | I used to be famous for totally different things on .fi and on .com |
| 23:01 | <Philip`> | Better than not being famous at all |
| 23:01 | <roc> | grrr |
| 23:02 | <roc> | My war with Eminem has no end ... http://www.google.com.au/search?q=I'm+back |
| 23:03 | <hsivonen> | zeldman is still in the lead: http://www.google.com/search?q=doctype |
| 23:03 | <othermaciej> | roc: are you the real Slim Shady? |
| 23:05 | <roc> | your sophisticated hip-hop references are lost on me |
| 23:07 | <Hixie> | you'd think that chris and dan would have given up on the html telecons by now |
| 23:08 | <othermaciej> | heh |
| 23:08 | <Hixie> | there are three people on the call. a chair, a w3c staff contact (who has no choice), and someone who just dropped off, who i think is laura |
| 23:09 | <Dashiva> | How many active on IRC? |
| 23:09 | <Hixie> | four |
| 23:09 | <Hixie> | two of which are IRC bots |
| 23:10 | <Philip`> | Sounds like the bots are beginning to take over |
| 23:10 | <Hixie> | strange place to start |
| 23:10 | <Hixie> | the htmlwg telecons :-) |
| 23:10 | <Philip`> | When humans succumb to apathy, their creations will rule the world |
| 23:12 | <Hixie> | six people active! |
| 23:12 | <Hixie> | well, four, and two bots |
| 23:12 | <Hixie> | the other two people being anne and myself, who apparently were both watching! |
| 23:13 | Philip` | wonders why users who explicitly disable significant browser features should expect a good user experience |
| 23:14 | <Hixie> | hm? |
| 23:15 | <Philip`> | (Recent public-html email) |
| 23:15 | <Hixie> | ah |
| 23:29 | <Dashiva> | Philip`: Disabling scripting actually improves the user experience on some sites :) |
| 23:39 | <gsnedders> | It breaks a grand total of nothing on my site. |
| 23:40 | <gsnedders> | But there again, I see no need for scripting on my site. |