| 00:37 | <Hixie> | did shelley just formally object to the free market philosophy? |
| 01:00 | <gavin_> | where? |
| 01:18 | <Lachy> | Hixie, why are you surprised? Shelly objects to everything that doesn't result in getting what she wants |
| 02:13 | <Lachy> | http://twitter.com/minusfive/status/2524514401 |
| 02:13 | <Lachy> | "@Lachy "you misunderstand. <font> is non-conforming, validators will give an error" - please share your sources? #html5" |
| 02:19 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#font |
| 02:27 | <Lachy> | thanks. I was looking for where the spec said that authors could only used the defined elements and attributes, but that list is good enough |
| 02:32 | <Lachy> | damn, I really can't keep up with the absurd volume of e-mail on public-html and whatwg. I had 0 mails left in either of those lists earlier today (after ignoring a whole bunch), and it's now up to 46 unread (combined) in just 12 hours |
| 02:33 | <Lachy> | and that's already after having read quite a few of them in the mean time |
| 02:36 | <Lachy> | I'll have to read them all in the morning. Hopefully there won't be another 50 by the time I wake up! |
| 02:37 | <tantek> | Lachy - email doesn't scale. Eventually you'll give up on efail. |
| 02:37 | <Lachy> | tantek, what's the alternative? |
| 02:38 | <Lachy> | the big problem is that the codec and summary threads are largely repetitive. |
| 02:40 | <tantek> | Lachy - the alternative is to put content on the wiki, and have email/IRC only for sharing updates/URLs |
| 02:40 | <tantek> | http://tr.im/wikibetter |
| 02:41 | <tantek> | more on EMAIL is EFAIL: http://tantek.com/log/2008/02.html#d19t2359 |
| 02:43 | <Lachy> | tantek, I strongly disagree. Wikis are subject to edit wars and are not optimised for discussion purposes. |
| 02:44 | <Lachy> | they're even worse than forums for discussion purposes |
| 02:45 | <Lachy> | anyway, bed time. Good night. |
| 03:08 | <Hixie> | Lachy: try joining www-font |
| 03:09 | <Hixie> | 50 a day so far this month |
| 03:11 | <Hixie> | http://blog.halindrome.com/2009/07/w3c-you-ignorant-slut.html?showComment=1247014132596#c5389136712076824446 |
| 03:15 | <othermaciej> | oh jesus, www-font |
| 03:23 | Hixie | ponders the bibtex vocabulary |
| 03:23 | <othermaciej> | omg I got +1d by John Foliot |
| 03:26 | <Hixie> | the main use case for the bibtex stuff was drag-and-drop of content from one page into another (e.g. a wikipedia entry) with the destination having a script that automatically took the biblio data from the first page and added it to the second page's references |
| 03:27 | <othermaciej> | it seems to me that, on the one hand, that use case doesn't sound terribly common, and on the other hand, it could be served via script and agreed convention in absence of native support |
| 03:27 | <Hixie> | yeah |
| 03:28 | <Hixie> | ok i'm gonna strip the bibtex vocabulary out. it wasn't that popular in the first place. |
| 03:30 | <othermaciej> | I do think personal information and calendar events are of greater general interest |
| 03:30 | <Hixie> | yeah |
| 03:57 | <heycam> | re flexbox and css animation on http://wiki.whatwg.org/wiki/Companion_specifications, i think both have active editors |
| 03:59 | <dbaron> | does anybody know where the message was where the XHTML2 WG announced that XHTML2 would use the 1999 namespace? |
| 04:00 | <othermaciej> | I remember seeing it in the w3c archives but I don't remember where |
| 04:01 | <dbaron> | yeah, that's my current problem |
| 04:02 | <othermaciej> | I think it was posted by Shane McCarron |
| 04:05 | <dbaron> | well, I can cite http://lists.w3.org/Archives/Public/public-html/2007Jun/0313.html since I haven't found anything better |
| 04:05 | <othermaciej> | I think this might be the email I was thinking of: http://lists.w3.org/Archives/Public/public-xhtml2/2007Jun/0014.html |
| 04:06 | <othermaciej> | other than that, I've only seen discussion in minutes I think |
| 04:06 | <dbaron> | http://lists.w3.org/Archives/Public/www-html-editor/2006JulSep/0137 too |
| 04:06 | <othermaciej> | ah, that might have also been one I was thinking of |
| 04:07 | othermaciej | pats self on the back for remembering who posted it |
| 04:07 | <dbaron> | See, I remember one that Lachy wrote a good response to that I wanted to link to |
| 04:07 | <dbaron> | but I can't find it |
| 04:07 | <dbaron> | maybe it was on a member-confidential list |
| 04:11 | <othermaciej> | I see this from Lachlan: http://lists.w3.org/Archives/Public/www-html/2006Oct/0014.html |
| 04:12 | <dbaron> | no, I remembered something else more directly about the namespace |
| 04:12 | <dbaron> | but I have another link that makes the same point, although not quite as well, but well enough |
| 04:13 | <othermaciej> | xhtml2 is dead anyway, are you looking to desecrate the body? |
| 04:15 | <dbaron> | I was just writing a short post-mortem. |
| 04:16 | <othermaciej> | to me one of the weirdest events in the history of xhtml2 was Sam Ruby's "merger" proposal on his blog which seemed to capture no interest whatsoever in the HTML WG |
| 04:16 | <othermaciej> | even though I believe there was much intense private discussion preceding it |
| 04:20 | <sayrer__> | dbaron, sam ruby wrote on that |
| 04:20 | <dbaron> | sayrer__, on what? |
| 04:23 | <MikeSmith> | dbaron: I seem to remember looking for an archived message with such an announcement, and never being able to find one |
| 04:23 | <MikeSmith> | I think they may have never actually announced it |
| 04:23 | <dbaron> | MikeSmith, http://lists.w3.org/Archives/Public/www-html-editor/2006JulSep/0137 is one |
| 04:23 | <MikeSmith> | OK |
| 04:24 | <sayrer__> | dbaron, http://www.w3.org/html/wg/tracker/actions/105 |
| 04:25 | <dbaron> | I'm looking for a particular message that was probably second half of 2006 or maybe early 2007 |
| 04:25 | <dbaron> | or was, rather |
| 04:28 | <sayrer__> | http://lists.w3.org/Archives/Public/public-html/2007Oct/0385.html |
| 04:28 | <sayrer__> | getting warmer |
| 04:28 | <sayrer__> | but if you're not looking |
| 04:28 | <sayrer__> | nevermind then |
| 04:52 | <roc> | wow |
| 04:52 | <roc> | Tom Lord's latest to www-font really ups the ante |
| 04:54 | <roc> | http://lists.w3.org/Archives/Public/www-font/2009JulSep/0341.html for those following along at home |
| 04:58 | <dbaron> | I think http://lists.w3.org/Archives/Public/www-html-editor/2006OctDec/0014.html actually probably was the post I was thinking of |
| 04:59 | <dbaron> | and wasn't as clear as I remembered in explaining what "backwards compatible" meant |
| 05:47 | <othermaciej> | my car crash curiosity is aroused |
| 05:49 | <othermaciej> | roc: was he high when he posted that? |
| 05:50 | <roc> | I hope so |
| 05:50 | <othermaciej> | true, it would be much more disturbing if he wasn't |
| 05:50 | <othermaciej> | I wonder how he came to be so very interested in this issue |
| 06:26 | <shepazu> | Lord's comment is more or less what Chris Wilson argued to me and David Storey at Google I/O (minus the wise holy streetperson) |
| 06:27 | <shepazu> | no, correction... it was me and Arun, not David Storey |
| 06:30 | <sayrer__> | "Lord's comment is more or less what Chris Wilson argued to me " |
| 06:30 | <sayrer__> | lol |
| 06:31 | <sayrer__> | then I got to the end and the joke was over |
| 06:31 | <shepazu> | sayrer: I meant that in the sense of "Lord's Prayer"... I'm a lapsed Catholic, and I still have messianic visions of the lotus and the Beast |
| 07:02 | <othermaciej> | shepazu: I doubt that Chris Wilson argued the "also support straight TTF" part |
| 07:17 | <shepazu> | othermaciej: correct... just the bit that says "The EOT-lite part makes sense because, done correctly, it allows interop with already deployed versions of IE." |
| 07:40 | <hsivonen> | Hixie: I saw the discussion between you and maciej on IRC, but I'm unsure which email is expecting my reply. Could you help me with an URI, please? |
| 07:41 | <Hixie> | sure, hold on |
| 07:42 | <Hixie> | http://lists.w3.org/Archives/Public/public-html/2009Jul/0227.html |
| 07:42 | <Hixie> | but see also related thread messages |
| 07:42 | <hsivonen> | thanks |
| 07:44 | <othermaciej> | hsivonen: we were discussing whether non-fatal warnings might be a better kind of less-sever diagnostic than down-played errors as they currently stand, and also the possibility of applying that to summary="" |
| 07:44 | <othermaciej> | note: it might be legitimate to make lack of alt="" a nonfatal warning |
| 07:44 | <othermaciej> | since the spec says you should include alt except in exceptional circumstances |
| 07:44 | <hsivonen> | I don't like downplayed errors |
| 07:45 | <hsivonen> | I also don't like prescribed warnings |
| 07:45 | <hsivonen> | but I like downplayed errors less |
| 08:08 | <hsivonen> | my spirits sink reading sicking's description of what IE does with deferred doc.write |
| 08:09 | <hsivonen> | (the innerHTML part) |
| 08:10 | <Hixie> | when i specced defer="" i left a comment in the spec to the effect that i knew it didn't match IE but i was hoping no-one would notice :-/ |
| 08:11 | <othermaciej> | I can't think of any possible thing to do with deferred document.write that would be sane |
| 08:15 | <Philip`> | Hixie: The mails to commit-watchers seem to indicate that changes to source are not getting propagated to index |
| 08:16 | <Hixie> | that is correct |
| 08:16 | <Hixie> | the changes in the recent checkins went to the IETF |
| 08:17 | <gsnedders> | Philip`: Pfff. Coward! Just read the spec and check what was updated. |
| 08:17 | <Hixie> | they were WebSocket changes |
| 08:17 | <Philip`> | Oh |
| 08:17 | <Philip`> | Whoops |
| 08:57 | hsivonen | wonders if zeldman's comments have different moderation behavior at differt times of day |
| 08:57 | <hsivonen> | that is, if you go to queue when it's night on Zeldman's time zone and straight to public when it's day |
| 08:59 | <hsivonen> | well, maybe my comment appears some time |
| 09:07 | hsivonen | wonders if Google is really going to keep Dalvik apps around or if Android is going Palm Pre now that they are doing the Chrome OS thing |
| 09:07 | <Hixie> | ok |
| 09:08 | <Hixie> | opinions on the new obsolete section? http://www.whatwg.org/specs/web-apps/current-work/#obsolete-features |
| 09:08 | <othermaciej> | hsivonen: Google just recently announced a native C++ SDK for Android I think |
| 09:08 | <Hixie> | see also changes under DOCTYPEs here: http://www.whatwg.org/specs/web-apps/current-work/#the-initial-insertion-mode |
| 09:08 | <othermaciej> | hsivonen: so it sounds more like they are going the other way with it |
| 09:09 | <gsnedders> | othermaciej: So how will they cope with non-ARM Android devices? |
| 09:09 | <othermaciej> | gsnedders: no idea! fat binaries? |
| 09:09 | <hsivonen> | looks like Web apps are the only thing that works across all these devices... |
| 09:09 | <gsnedders> | othermaciej: How will they cope with arch_that_doesn't_exist_yet? |
| 09:10 | <othermaciej> | gsnedders: you should probably ask someone who knows and understands the strategy |
| 09:10 | <hsivonen> | gsnedders: the question is even more interesting for Google Native Client if it catches on |
| 09:10 | <othermaciej> | iPhone's strategy is to lock down the hardware platform and severely limit number of available models so you know what your native apps are targeting |
| 09:10 | <gsnedders> | othermaciej: But I don't know anyone who does, so asking in IRC is the best thing I can do :) |
| 09:10 | <T--> | Hixie, just out of curiosity, what's the rationale of choosing iframes over framesets? |
| 09:11 | <hsivonen> | Hixie: "na name" |
| 09:12 | <Hixie> | T--: they're more flexible, and we can't really get rid of them (they're used everywhere) |
| 09:12 | <Hixie> | hsivonen: fixed |
| 09:12 | <othermaciej> | I would personally lean towards profile="" in the obsolete but conforming bucket, but say HTML processors MUST NOT vary their processing based on it |
| 09:13 | <othermaciej> | wording looks good to me though |
| 09:13 | <othermaciej> | I think this is an improvement over "downplayed errors" |
| 09:14 | T-- | doesn't understand the ?flexible?. |
| 09:14 | <hsivonen> | Hixie: where's the normative statement that validators must warn about those? |
| 09:14 | <Hixie> | hsivonen: last subsection of that h2-level section |
| 09:14 | <Hixie> | i can move it up if you like |
| 09:14 | <hsivonen> | Hixie: works for me as is |
| 09:15 | <Hixie> | i've moved it up |
| 09:15 | <hsivonen> | ok |
| 09:28 | <jgraham> | So "obsolete" is the new "deprecated" |
| 09:28 | Hixie | growls at bug 7089 |
| 09:28 | <Hixie> | jgraham: it always has been, hasn't it? |
| 09:29 | <jgraham> | Well I mean "obsolete"+warning |
| 09:29 | <Hixie> | the big difference between Transitional and the warnings is that you don't ever see "Your document is conforming!" if you have warnings, you see "You document is conforming, but with warnings" |
| 09:30 | <Hixie> | with transitional, once you had the transitional doctype, you never again saw anything clearly telling you that you weren't strict |
| 09:30 | <Hixie> | at least, i reckon that's a difference |
| 09:30 | <jgraham> | Given how popular compiler warnings are I can't imagine it will make a big difference |
| 09:30 | <Hixie> | true |
| 09:30 | <Hixie> | oh well, we'll see |
| 09:30 | <Hixie> | there's not much on the list |
| 09:31 | <othermaciej> | jgraham: are you saying compiler warnings are popular, or unpopular? |
| 09:31 | <jgraham> | othermaciej: I assume they are popular because compiling software tends to give me so many of them ;) |
| 09:31 | <othermaciej> | heh |
| 09:32 | <othermaciej> | WebKit builds with -Werror (or equivalent) and with many optional warnings on |
| 09:32 | <othermaciej> | (although in MSVC we have to turn some off, because they are stupid) |
| 09:32 | <jgraham> | (In seriousness, I know that many projects have a zero-warnings policy but it hardly seems to be normal and in web-developert terms probably translates onto the people who would care about the strict/transitional distinction) |
| 09:33 | <othermaciej> | for example, if you use a high enough warning level and don't silence this one specifically, MSVC will complain if you write if (intVariable) { something(); } |
| 09:33 | <othermaciej> | it wants you to say if (!!intVariable) { something(); } |
| 09:34 | <jgraham> | what's the difference? |
| 09:34 | <othermaciej> | in generated code and actual effect? nothing |
| 09:34 | <othermaciej> | but for the former, it complains about an implicit conversion to bool |
| 09:35 | <Hixie> | and !!a isn't an implicit conversion?! |
| 09:35 | <Philip`> | (if (intVariable != 0) seems nicer to read) |
| 09:35 | <othermaciej> | and warns you that it may be slow, or something |
| 09:35 | <othermaciej> | I'm not giving this as an example of a good warning! |
| 09:36 | <Philip`> | The Intel C++ Compiler has "info" (I think) messages, as well as errors and warnings, which say things like "order of argument evaluation is undefined" that aren't serious enough to be warnings |
| 09:38 | <Hixie> | ok bed time |
| 09:38 | <Hixie> | nn |
| 09:39 | <Philip`> | I always get tempted to waste time avoiding any messages the compiler might output, even if they're really pointless and I shouldn't care |
| 09:39 | <Philip`> | since I'm just incapable of ignoring them |
| 09:39 | <Philip`> | and it takes a lot of effort to convince myself to lower the verbosity setting |
| 09:39 | <othermaciej> | for WebKit we basically choose to make compiler or analysis tool messages either fatal or silenced |
| 09:42 | <hsivonen> | othermaciej: that flavor of compiler warning would have helped me avoid one classic if (foo = bar) bug in the HTML5 parser |
| 09:42 | <othermaciej> | hsivonen: gcc warns you if you write if (foo = bar) |
| 09:42 | <othermaciej> | hsivonen: it tells you that if you really meant to do that, you should put parentheses around it |
| 09:42 | <Lachy> | Hixie, in #conforming-but-obsolete-features section, you basically give the same list twice, but written in slightly different ways. |
| 09:42 | <othermaciej> | that's much better than the GCC warning |
| 09:43 | <Lachy> | oh, I see. The first is for authors. The latter is the UA conformance requirements |
| 09:43 | <Lachy> | Didn't make sense before I turned on the highlighting stylesheet |
| 09:45 | <hsivonen> | othermaciej: what really happened here is that I made the change quickly late in a review cycle for landing, so I only checked it compiled--I didn't take a good look at warning/assert smoke |
| 09:45 | <hsivonen> | so I guess no warning would have saved me |
| 09:45 | <othermaciej> | -Werror would have saved you |
| 09:46 | <othermaciej> | because then it wouldn't have compiled |
| 09:47 | <Lachy> | Hixie, with the "Hide UA text" stylesheet enabled, the link to "obsolete permitted DOCTYPEs" from the "Conforming but obsolete features" section no longer works because that's written in a .impl section |
| 10:03 | <Lachy> | re that discussion on www-font, it would suck to even allow EOT-lite, cause then we'll get stuck with DRM-encumbered fonts from major font vendors, even though the DRM is entirely ineffective and only serves as a hinderence to authors |
| 10:03 | <Lachy> | s/allow/require/ |
| 10:05 | <Lachy> | just make ttf/otf mandatory. Authors can still provide EOT versions as a fallback font that will work in older versions of IE, at least until support for ttf/otf is widely deployed in more up to date versions of IE |
| 10:06 | <Lachy> | Are Microsoft still objecting to supporting TTF/OTF? |
| 10:06 | <othermaciej> | Web fonts, the other format war |
| 10:07 | <othermaciej> | Chris Wilson gave a really clear flat refusal |
| 10:08 | <Lachy> | It really makes me wonder where Microsoft's interests lie: In providing the best development platform for authors, or for giving in and promoting the absurd needs of the font-foundries?! |
| 10:10 | <Lachy> | I guess it's the same underlying philosiphy that Microsoft uses to push various forms of DRM on other types of media |
| 10:11 | <Philip`> | What is the argument against permitting fonts in a format that can't easily be reused outside the web? (separate from the arguments against not supporting TTF/OTF) |
| 10:12 | Philip` | is interested since his font subsetting tools makes fonts that can't easily be reused outside the web (or outside the context where they were originally used), and wonders if that's considered a bad thing |
| 10:13 | jgraham | hasn't been following the discussion but thought the issue was more to do with tying fonts to specific domains making testing a pain |
| 10:13 | <jgraham> | s/testing/deployment/ |
| 10:13 | <Lachy> | EOT places restrictions on what domains a font can be used on and expects browsers to enforce those restrictions. |
| 10:14 | <Lachy> | (I could be remembering that wrongly, but I know the font foundries have been pushing for a feature like that in one form or another) |
| 10:15 | <Philip`> | If you could e.g. tweak a TTF/OTF so that it works fine in web browsers but is kind of broken if used in many other applications, e.g. by setting the embedding bits or setting the font name to "", would that be considered harmful to the world? |
| 10:25 | <Lachy> | yes, because it imposes what could be considered to be a Technological Protection Measure on the font, and could be subject to anti-circumvention clauses of laws like the DMCA. |
| 10:25 | <Lachy> | It would be the font equivalent of the failed broadcast flag proposal |
| 10:27 | <Lachy> | also, that's one of the proposals that was discussed on www-style a long time ago |
| 10:28 | <Lachy> | and I recall someone from the Linux community saying that support for the flag would have to be integrated into the systems font handling, and thus wouldn't protect against other uses on the system anyway |
| 13:12 | <takkaria> | I don't think the new warning model will be like Transitional, on reflection, because you can't turn the warnings off by putting a toggle in your source file |
| 13:13 | <gsnedders> | takkaria: You feeling better? |
| 13:13 | jgraham | was about to ask that |
| 13:13 | <takkaria> | well, I'm standing up and lighgt doesn't hurt now. :) |
| 13:13 | gsnedders | sticks tongue out at jgraham |
| 13:14 | <takkaria> | still a bit of a headace but that's bearable |
| 13:17 | <jgraham> | Nice weather we have here |
| 13:19 | <gsnedders> | Yeah, absolutely lovely. |
| 13:42 | <hsivonen> | Lachy: the WHATWG WordPress isn't up-to-date |
| 13:43 | <hsivonen> | Lachy: Akismet is out of date, too |
| 13:46 | <Lachy> | hsivonen, yeah, I noticed that yesterday |
| 13:46 | <Lachy> | I suppose I could update it now |
| 13:48 | <hsivonen> | hmm. did I just blog with a grammar error in the title? |
| 13:48 | <Lachy> | upgarded now |
| 13:48 | <hsivonen> | should it be "Help test" instead? |
| 13:48 | <Lachy> | yes |
| 13:49 | <Lachy> | or "Help With Testing..." |
| 13:49 | <Lachy> | but Help Test seems better |
| 13:49 | <hsivonen> | Lachy: thanks |
| 13:50 | <hsivonen> | fixed. |
| 13:51 | <Lachy> | plugins upgraded now too |
| 13:51 | <hsivonen> | thanks |
| 13:51 | <Lachy> | I should also check that our wiki installation is up to date as well later |
| 13:52 | <hsivonen> | it's been quite a while since the last "this week" |
| 13:52 | <Lachy> | but that takes a little more effort, since I don't have a script for it |
| 14:04 | <hsivonen> | how should this quote be read? http://twitter.com/markbirbeck/status/2388701600 |
| 14:10 | <Lachy> | I have no idea what it means for something to "be highest impact" |
| 14:11 | <karlcow> | trying to look for more background in http://twitter.com/#search?q=%23swdag2009 |
| 14:11 | <takkaria> | RDFa is falling as part of a meteor shower of general web technology, and out of all of the meteorites that will hit the earth, RDFa will be highest impact |
| 14:12 | <Dashiva> | Meaning it will hit a mountain? |
| 14:12 | <Lachy> | hsivonen, I'm curious what the practical difference will be as far as implementing downplayed errors vs. the new conforming but obsolete warnings. |
| 14:13 | <Dashiva> | I could read it as "be [the one with the] highest [degree of] impact" |
| 14:13 | <Lachy> | I thought downplayed errors meant that warnings should be issues, rather than full errors |
| 14:13 | <Lachy> | so it's not clear to me that these spec changes are anything more than superficial |
| 14:15 | <karlcow> | the ajax search call in twitter is killing my firefox |
| 14:19 | <hsivonen> | Lachy: warnings don't need new UI code, so they are easier |
| 14:20 | <Lachy> | hsivonen, sure, but how is issuing warnigns for the current spec different from issuing warnings for downplayed errors? Or would something else have been done for that? |
| 14:21 | <hsivonen> | Lachy: downplayed errors would have counted towards making the result turn into invalid |
| 14:21 | <hsivonen> | Lachy: and the vision for downplayed errors was that they'd sort and collapse differently |
| 14:38 | <Lachy> | hsivonen, that sounds like little more than UI design decisions that aren't really affected by what the spec actually said. |
| 14:40 | <hsivonen> | Lachy: the non-UI effect is that the presence of one or more downplayed errors made the document invalid but the presence of normative warnings doesn't |
| 14:49 | <Lachy> | so it's a very fine line between "non-conforming, but ignorable errors" and "conforming, but with warnings" |
| 14:52 | <Philip`> | "non-conforming, but ignorable errors" wouldn't give you a badge |
| 14:52 | <Philip`> | (Maybe the other won't either, which makes them harder to distinguish) |
| 15:01 | <sayrer__> | Lachy: sometimes validator authors are nervous about stepping outside of what the spec tells |
| 15:01 | <sayrer__> | tells them is "invalid" |
| 15:24 | <Lachy> | it seems really strange that with so many browsers over the years, the idea of creating a browser OS keeps coming up. It happened with Netscape. It happened with Firefox, and now it's happening with Chrome. I suspect the only reason it didn't really happen with IE is that it was already so closely linked to Windows anyway, it wouldn't make much difference |
| 15:24 | <Lachy> | -- http://arstechnica.com/web/news/2009/07/google-chrome-os-lives-and-is-coming-to-a-netbook-near-you.ars |
| 15:28 | <karlcow> | [10:04] <sayrer__> Lachy: sometimes validator authors are nervous about stepping outside of what the spec tells |
| 15:28 | <karlcow> | indeed. And what ever option you are choosing you get shot for your choices. |
| 15:29 | <karlcow> | been there, seen that (aka w3c markup validator communitie*S*) |
| 15:29 | <sayrer__> | I think the author conformance requirements would be better in a document titled "How to write high quality HTML" |
| 15:30 | <sayrer__> | then the validator could say "Don't you want to write high quality HTML?" |
| 15:31 | <Dashiva> | "Why do you hate freedom?" |
| 15:33 | <Philip`> | "The Android browser has very little in common with Chrome on the desktop (for example, the Android browser uses Apple's SquirrelFish JavaScript engine instead of Chrome's V8)." - apart from having, like, all of WebKit in common? |
| 15:33 | <Lachy> | I guess WebKit is just a very minor and insificant part of the browser, compared with the JavaScript engine |
| 15:34 | <Lachy> | </sarcasm> |
| 15:34 | <MikeSmith> | Philip`: where do that quote come from? |
| 15:34 | <Lachy> | sayrer__, how to write high quality HTML should be explained in HTML5 guides and references. Normative conformance criteria belong in the spec |
| 15:35 | <Philip`> | MikeSmith: The Ars article to which Lachy linked |
| 15:35 | <MikeSmith> | ok |
| 15:35 | <sayrer__> | Lachy: sure |
| 15:36 | <MikeSmith> | Lachy: I suspect sayrer__'s point is that they shouldn't be normative conformance criteria |
| 15:36 | <Lachy> | but then that wouldn't be very useful |
| 15:37 | <sayrer__> | useful for producing interoperable markup? |
| 15:38 | <Lachy> | sayrer__, while we could very easily get interoperability between implementations without any authoring conformance criteria, normative conformance criteria are essential to ensure conformance checkers are interoperable and to help authors write markup properly |
| 15:39 | <sayrer__> | you mean lint tools must produce the same result for all input? |
| 15:39 | <karlcow> | interesting that the dicussion around canonical html is coming back :) |
| 15:39 | <sayrer__> | "properly" is not an objective quality |
| 15:40 | <sayrer__> | and I'll note that conformance checker interoperability is not something the WG is chartered to take on |
| 15:40 | <sayrer__> | but it seems tangential to me, since conformance checkers are supposed to be the means, not the end |
| 15:40 | <Lachy> | no, I mean conformance checkers and validators. Lints offen flag stuff that isn't necessarily non-conforming, but which you might like to consider fixing anyway |
| 15:41 | <Lachy> | s/offen/often/ |
| 15:41 | <sayrer__> | why do you need checker/validator rather than a lint tool? |
| 15:42 | <Lachy> | it depends on your individual needs and the capabilities of the lint tool in use |
| 15:43 | <Lachy> | e.g. you might have a lint which checks that an HTML document fits the criteria necessary for being a syntactically correct polyglot document, but which doesn't check any other conformance criteria. |
| 15:43 | <sayrer__> | I guess I don't understand whats motivating your position. do you feel validators force people to write good markup in some way? |
| 15:45 | <Lachy> | no, validators are very useful QA tools to help ensure the quality of the markup and catch mistakes. Conformance criteria help to ensure that different people are using a comment set of criteria, whcih makes it easier for developers to work together |
| 15:45 | <sayrer__> | common set of criteria? |
| 15:46 | <sayrer__> | lint tools are "are very useful QA tools to help ensure the quality of the markup and catch mistakes." |
| 15:46 | <sayrer__> | agree or disagree? |
| 15:46 | <sayrer__> | my feeling is that if you want validators to interoperate, you would make rules for validators |
| 15:46 | <Lachy> | partially agree. I've had experience with some lint tools that report useless information that I didn't need. But, they can be depending on your needs |
| 15:47 | <Lachy> | and also experience with lints that fail to report info that I do need |
| 15:48 | <Lachy> | sayrer__, the authoring conformance criteria in the spec do apply to validators. It says that explicitly in the conformance section |
| 15:49 | <sayrer__> | yes, I don't think that makes much sense. |
| 15:49 | <sayrer__> | validators aren't authors |
| 15:49 | <Lachy> | validators check markup on behalf of authors |
| 15:50 | <Lachy> | and if there weren't a common set of conformance criteria defined, then validators would vary significantly in what they report, and they wouldn't be particularly useful |
| 15:51 | <Lachy> | with a common set of criteria, developers can, in theory, use their favourite validation tools (perhaps based on the UI they like most) and be reasonably sure that they'll get equivalent results. |
| 15:52 | <sayrer__> | I am not sure how that became a goal, and it still seems tangential, since conforming HTML5 UAs will produce equivalent results no matter what |
| 15:52 | <Lachy> | I honestly do not understand your POV. |
| 15:52 | <sayrer__> | well, let's say one validator flags <font> and one doesn't |
| 15:53 | <sayrer__> | and the author happens to be using the validator that doesn't |
| 15:53 | <sayrer__> | so a <font> element has slipped through undetected |
| 15:53 | <sayrer__> | what is the interoperability consequence? |
| 15:54 | <Lachy> | that seems like a problem that only applies to your authoring-conformance-free spec |
| 15:54 | <sayrer__> | well, you are saying validators won't be useful without the requirements we have now |
| 15:54 | <sayrer__> | in a world without them, I expect some problems will occur if you are right |
| 15:55 | <sayrer__> | what is the problem that has occured here? |
| 15:56 | <Lachy> | from a browser POV, there isn't an interoperability issue. The issue is that different tools give authors different results. This reduces their ability to rely on tools to give useful results and could cause different people to argue about what's right and what's wrong, based on nothing more than the implementation decision of their favourite QA tools |
| 15:59 | <sayrer__> | so all validators must produce identical results? |
| 15:59 | <sayrer__> | and is it so bad if people argue about what's right and wrong? |
| 16:00 | <Lachy> | ideally, yes, as far as issuing errors is concerned. They can issue additional useful warnings based on the user's need |
| 16:00 | <Lachy> | or, actually, the user's desires |
| 16:00 | <sayrer__> | is that requirement in the spec? |
| 16:01 | <Lachy> | there's nothing in the spec to say that they can't issue additional warnings |
| 16:01 | <sayrer__> | is there a requirement that they must not issue additional errors? |
| 16:01 | <sayrer__> | otherwise, different tools could give different results |
| 16:01 | <Lachy> | no, tools are only allowed to issue errors defined in the spec |
| 16:02 | <sayrer__> | oh, I missed that. where is it? |
| 16:04 | <Lachy> | if it issues an error, or even treates something as a fatal error, where the spec doesn't say it can, then it has violated the actual criteria specified which doesn't say to issue an error |
| 16:07 | <sayrer__> | so then it couldn't issue an error for elements developed later |
| 16:07 | <sayrer__> | or elements in other namespaces |
| 16:07 | <sayrer__> | afaik, there are no fatal errors in HTML5 |
| 16:08 | <sayrer__> | so far, I don't think there's anything in the spec that will enforce the level of interoperability you claim |
| 16:08 | <Lachy> | a spec that defines new elements would also update the relevant conformance criteria |
| 16:08 | <Lachy> | elements in other namespaces have their own criteria applying to them defined in their respective specs |
| 16:11 | <Lachy> | the parsing requirements allow implementations to treat errors as fatal instead of applying the corrective steps specified. |
| 16:12 | <Lachy> | "The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below." |
| 16:13 | <sayrer__> | oh, that's very damaging to interoperability |
| 16:13 | <sayrer__> | but I thought that hedge existed for validators |
| 16:13 | <sayrer__> | it seems to have changed |
| 16:14 | <Lachy> | it depends on the needs of the specific implementation. Browsers, for example, couldn't really get away with aborting on errors in practice. But there are lots of other tools for which graceful error recovery is not essential |
| 16:15 | <Lachy> | A validator is one such use case for that |
| 16:15 | <Philip`> | Some (non-validator) tools really want streamability, and aborting on certain parse errors lets them do that |
| 16:15 | <sayrer__> | Lachy: not sure it is useful to claim they are conformant to the same spec |
| 16:15 | <sayrer__> | Philip`: yeah, a spider for instance |
| 16:15 | <Philip`> | (and they can streamably handle all conforming documents) |
| 16:16 | <sayrer__> | that last part is not true, since they can streamably all non-scripted conforming documents |
| 16:16 | <sayrer__> | streamably handle |
| 16:16 | <Lachy> | from memory, the adoption agency algorithm is one that affects streamability |
| 16:17 | <Philip`> | sayrer__: I'd expect most spiders would want to accept arbitrary input, and so they'd have to non-fatally handle invalid documents |
| 16:17 | <Lachy> | (hsivonen knows more about that, though) |
| 16:17 | <sayrer__> | Philip`: that's good point |
| 16:18 | <sayrer__> | I'll make a note about this |
| 16:18 | <Philip`> | sayrer__: I'm thinking of e.g. a tool that applies some kind of transformation to an HTML document, and doesn't want to buffer the whole document in memory |
| 16:18 | <Lachy> | sayrer__, tools that wish to incorporate an HTML5 parser into existing XML tool chains, and which require streamability, are likely to opt to abort on some errors |
| 16:19 | <Lachy> | e.g. a CMS that allows the author to write HTML, but which uses XML for everything else on the back end |
| 16:19 | <sayrer__> | they will probably opt out of more than just that |
| 16:21 | Philip` | wrote a web service that converts HTML to XHTML streamingly, but (if he remembers correctly) it also aborted on cannot-serialise-to-XML errors |
| 17:58 | <Philip`> | http://hacks.mozilla.org/2009/07/video-more-than-just-a-tag/ - "<video id="myVideo" src="myFile.ogv"/>" - isn't that syntax going to break badly? |
| 18:11 | <Lachy> | we really should do more to promote better quality fallback, beyond the useless "You're browser doesn't support this" |
| 18:12 | <Lachy> | even a simple <a href="video.ogg">Download and watch</a> would be better |
| 18:23 | <Dashiva> | I could imagine a script that generates fallback for video elements based on <source> and @src |
| 18:51 | <hsivonen> | Philip`: is your code for generating inputs that visit various tokenizer states publicly available? |
| 19:05 | <Philip`> | hsivonen: I think the latest version of the code is http://canvex.lazyilluminati.com/svn/tokeniser/ (particularly http://canvex.lazyilluminati.com/svn/tokeniser/test_gen.ml) |
| 19:05 | <Philip`> | though it's very out-of-date, and also very ugly |
| 19:05 | <Philip`> | and quite possibly quite buggy |
| 20:15 | <Hixie> | Lachy: there are lots of broken links from the author-only section |
| 20:25 | <Lachy> | ok |
| 20:26 | <Lachy> | that really makes it useless in many cases |
| 20:32 | <Hixie> | well like all the DOM stuff's <dfn>s are in the impl section |
| 20:32 | <Hixie> | so all the domintro green boxes point into the impl section |
| 20:32 | <Hixie> | not sure what to do about it |
| 20:33 | <jgraham> | Hixie: The sumamry attribute description looks OK to me but I suggest not referncing <caption> explicitly as a replacement, just the whole techniques section |
| 20:33 | <jgraham> | I think <a @name> could have a similar description |
| 20:35 | <jgraham> | like "This attribute was used in older versions of HTML to allow fragment identifiers o be associated with particular places in the document" |
| 20:37 | <Hixie> | how about saying it was similar to what ID does now |
| 20:38 | <Hixie> | checked in |
| 20:40 | <jgraham> | Hixie: perfect, thanks |
| 20:46 | <Hixie> | jgraham: btw, i think there's a difference between a whole spec, and a requirement in a spec |
| 20:46 | <Hixie> | jgraham: and in particular on the theora issue, the requirement in question is just importing another spec entirely, which i think is a particularly special case. |
| 20:50 | <jgraham> | Hixie: I agree that the theora thing is a somewhat different case |
| 20:50 | <jgraham> | But I think e.g. svg-in-HTML is quite a similar case |
| 20:52 | <jgraham> | in the sense that it is more useful to have a spec with support from 3/4 major vendors if one announces that they will not support it |
| 20:52 | <jgraham> | than to not have any spec at all |
| 21:29 | <Hixie> | jgraham: if they're going to implement regardless, then yes |
| 22:12 | <jgraham> | othermaciej: I think your proposed @summary text may be unnecessarily long and so unlikely to be read (the current text on alt has this problem) |
| 22:12 | <jgraham> | However I'm not sure |
| 22:15 | <othermaciej> | jgraham: it would be at the end of the already long section on how to provide table explanations |
| 22:15 | <othermaciej> | I think it is not overly long compared to the rest of that section |
| 22:15 | <othermaciej> | but |
| 22:15 | <othermaciej> | I am not wedded to my exact wording, it was just an example of how to provide the right information |