| 00:09 | <TabAtkins> | The "what's the language of the document" thread is the most boring thread in existence. Even worse than the process threads. |
| 00:27 | <Dashiva> | I wonder, the systems that use http-equiv content-language to assign metadata for use by the http server, how do they handle the language for non-html documents? |
| 00:34 | <AryehGregor> | paul_irish, if your page works in all major browsers including IE8 without browser-specific hacks, I think IE=edge is likely to be the most useful, because the next version of IE will probably implement more good features than bad. Moreover, the implications of X-UA-Compatible are rather evil, so I'd prefer to avoid it on principle if possible. |
| 00:37 | AryehGregor | ORLYs at http://www.mediawiki.org/w/index.php?title=HTML5&diff=0&oldid=311452 |
| 00:37 | AryehGregor | tests |
| 00:40 | <Dashiva> | I can see how it'd make the compression less efficient, but I can't see it leading to an increase in size compared to uncompressed |
| 00:42 | <Dashiva> | "Also note Manual:$wgValidateAllHtml, but is tidy ready for HTML5?" -- no |
| 00:47 | <AryehGregor> | It means that it would end up being larger than the version that uses quotes consistently. |
| 00:50 | AryehGregor | found not, although the difference is too trivial to matter by itself |
| 00:51 | AryehGregor | is wondering if he should move weird quoting to its own config option for people who don't like the aesthetics. |
| 01:08 | <Dashiva> | AryehGregor: If you through some magical incantation managed to start using a model to construct the page instead of string concatenation, it would almost solve itself |
| 01:09 | <AryehGregor> | What would almost solve itself? |
| 01:09 | <Dashiva> | The quoting |
| 01:09 | <Dashiva> | It would just be a parameter to the serialization |
| 01:10 | <AryehGregor> | It already is a parameter to the serialization, it's just currently rolled into $wgWellFormedXml. |
| 01:10 | <AryehGregor> | Search for "$quote": http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Html.php?view=markup |
| 01:11 | <AryehGregor> | Of course, that method isn't called everywhere we output an element. |
| 01:11 | <AryehGregor> | Partly because that would be too slow. Some places are pretty performance-sensitive for this sort of thing, I'm told. |
| 01:12 | <Dashiva> | Are there examples of such places? |
| 01:12 | <AryehGregor> | I've been told that if I make Sanitizer.php use Html::element(), I'll have my commit reverted, because extra function calls make a difference there. |
| 01:13 | <AryehGregor> | That's what ends up outputting stuff for the actual wikitext. |
| 01:13 | <Dashiva> | Isn't that... the majority of stuff? |
| 01:14 | <AryehGregor> | Yep! |
| 01:14 | AryehGregor | notices only 60 bytes saving after gzip on a large article for disabling $wgWellFormedXml, which is 0.6%. |
| 01:15 | <AryehGregor> | Even pre-gzip it's only 121 bytes. |
| 01:15 | <AryehGregor> | Er, no. |
| 01:15 | <AryehGregor> | It's 210 bytes pre-gzip. |
| 01:15 | <AryehGregor> | 0.5%. |
| 01:16 | <othermaciej> | TabAtkins: at lest it's relevant to the content of the spec |
| 01:16 | AryehGregor | wonders whether there's any actual point in making $wgWellFormedXml = false do anything other than change the doctype to <!doctype html>. |
| 01:18 | <Dashiva> | AryehGregor: Well, does it affect the skin? |
| 01:18 | <AryehGregor> | Parts of it. |
| 01:18 | <TabAtkins> | othermaciej: Glad to hear it. I try to start reading the thread and my brain shuts down out of self-defense. |
| 01:18 | <AryehGregor> | wiki.whatwg.org is using $wgWellFormedXml = false, so you can look there to see what's covered. |
| 01:18 | <AryehGregor> | It's not much. |
| 01:19 | <AryehGregor> | Most of the <head>. |
| 01:19 | <othermaciej> | well, the impact on the spec is off in the long tail where I don't care much about the specific outcome |
| 01:19 | <AryehGregor> | Basically nothing in the <body> |
| 01:20 | <AryehGregor> | . |
| 01:38 | <AryehGregor> | Is there a way in WebKit's Web Inspector to see styles that apply to pseudo-elements like ::-webkit-placeholder? |
| 01:40 | <AryehGregor> | Doesn't matter, I guess. |
| 01:40 | AryehGregor | struggles to find a color that light gray looks bad against. |
| 01:41 | AryehGregor | concludes "an almost exactly matching color of light gray" works |
| 01:41 | <othermaciej> | I don't think so, but that would be a good improvement |
| 01:49 | <JoePeck> | AryehGregor: write up a bug report at http://webkit.org/new-inspector-bug |
| 01:49 | <JoePeck> | AryehGregor: pfeldman (in #webkit-inspector) has been doing a lot of work recently with CSS Styles |
| 01:52 | <AryehGregor> | JoePeck, https://bugs.webkit.org/show_bug.cgi?id=36421 |
| 01:52 | <JoePeck> | AryehGregor: thanks! |
| 01:54 | <JoePeck> | AryehGregor: for what its worth, the user agent style is input::-webkit-input-placeholder { color: darkGray; } |
| 01:54 | <JoePeck> | not light gray? |
| 01:54 | <AryehGregor> | It's something like #bbb, so that seems right. |
| 01:54 | <AryehGregor> | CSS3 says darkgray is #a9a9a9. |
| 02:11 | <othermaciej> | How do you do nested lists in MediaWiki syntax> |
| 02:12 | <othermaciej> | I see, multiple *s |
| 04:33 | <AryehGregor> | Does anyone have stats on what doctypes are used? In particular, I'd expect XHTML 1.1 to be less common than XHTML 1.0 Strict, right? |
| 05:29 | <AryehGregor> | List of top 100 Alexa websites that validate according to the W3C: live.com, wikipedia.org, msn.com, wordpress.com, bbc.co.uk, mozilla.com, files.wordpress.com, thepiratebay.org. |
| 05:29 | <AryehGregor> | 8/98 checkable, it seems. |
| 05:29 | <AryehGregor> | I'm only checking the index page, of course. |
| 05:29 | <AryehGregor> | That's somewhat higher than I expected. |
| 05:30 | AryehGregor | notes two Microsoft sites validate, while all Google sites fail miserably. |
| 05:31 | <AryehGregor> | (The two uncheckable are 1e100.net and bp.blogspot.com, which don't actually resolve.) |
| 05:32 | <AryehGregor> | The next two fail, so I'll just say 8% of the top 100 Alexa domain names that actually resolve. |
| 05:34 | <othermaciej> | AryehGregor: that's what I found two |
| 05:34 | <AryehGregor> | s/two/too/? |
| 05:34 | <othermaciej> | yes |
| 05:35 | <othermaciej> | "too" |
| 05:35 | <AryehGregor> | And "that" meaning everything I said, or some particular part of it? |
| 05:35 | <AryehGregor> | Validation is much more common among the top 10 sites than among the top 100. |
| 05:35 | <AryehGregor> | I imagine it gets less common as you go down, really. |
| 05:35 | <othermaciej> | I started this page: http://www.w3.org/html/wg/wiki/ConformanceErrorStudy |
| 05:35 | <AryehGregor> | Ah, neat. |
| 05:36 | <othermaciej> | any data you can add would be appreciated |
| 05:36 | <AryehGregor> | I think Google doesn't use an HTML5 doctype, so much as independently choosing the shortest possible doctype that will avoid quirks mode (without regard to standards). |
| 05:36 | <AryehGregor> | How did you test? |
| 05:36 | <othermaciej> | I think classifying the errors and filing bugs on any that seem bogus is more productive than what Sam is doing |
| 05:36 | <AryehGregor> | What's Sam doing? |
| 05:36 | <othermaciej> | so instead of arguing with him I have started ding it myself |
| 05:36 | <othermaciej> | help would be appreicated |
| 05:36 | <othermaciej> | his weird "remove or replace author conformance requirements" bug |
| 05:36 | <AryehGregor> | And where are you filing bugs? On what basis? |
| 05:37 | <othermaciej> | where he refuses to get specific on what's wrong |
| 05:37 | <othermaciej> | I have not yet filed any bugs |
| 05:37 | <othermaciej> | my plan is to file some bugs against the spec in W3C bugzilla |
| 05:37 | <AryehGregor> | E.g., do you think we should propose that some common presentational attributes be made conforming in the spec? |
| 05:37 | <othermaciej> | that ask for removal or change of specific conformance requirements, if there are any that seem to be more noisy than beneficial |
| 05:38 | <othermaciej> | I haven't yet concluded whether to file a bug on presentational elements and attributes |
| 05:38 | <othermaciej> | my personal feeling is that there is not much benefit to making them nonconforming |
| 05:38 | <othermaciej> | AryehGregor: by the way, I do believe that google.com very deliberately chose <!DOCTYPE html> to match HTML5 |
| 05:38 | <othermaciej> | it used to have no doctype at all |
| 05:38 | <AryehGregor> | I have to say, it would be nice if like all Wikipedia articles didn't suddenly fail validation when we switch to HTML5. They tend to use presentational stuff all over the place. |
| 05:39 | <AryehGregor> | Oh, really? From looking at the HTML source, it looks to me like they're just trying to get the absolute minimum number of bytes possible. |
| 05:39 | <AryehGregor> | Oh, odd. |
| 05:39 | <AryehGregor> | They use <head>, and <meta http-equiv="content-type" content=etc.> instead of <meta charset>. |
| 05:39 | <AryehGregor> | So not sure my hypothesis works. |
| 05:40 | <othermaciej> | I suspect some of their use of presentational elements could be replaced with class names and CSS that are a smaller total number of source bytes |
| 05:40 | <othermaciej> | I also suspect that after gzip there will be no difference |
| 05:40 | <AryehGregor> | I've found that there's usually some difference after gzip. |
| 05:40 | <othermaciej> | I think part of the reason for the way google.com is written may be to work with pre-CSS UAs |
| 05:40 | <AryehGregor> | With this sort of thing. |
| 05:40 | <AryehGregor> | What pre-CSS UAs? |
| 05:41 | <othermaciej> | truly ancient browsers |
| 05:41 | <othermaciej> | I think google.com aims to target even the long tail of very rarely used browsers |
| 05:41 | <othermaciej> | but it's hard to say why they do what they do |
| 05:41 | <AryehGregor> | Yeah. |
| 05:41 | <AryehGregor> | "Unescaped & in URL attribute - 87" Is there any actual reason to prohibit this? |
| 05:41 | <othermaciej> | on most other pages that use presentational attributes, it seems to be an oversight, not a purposeful choice |
| 05:41 | <othermaciej> | I don't think unescaped & in URL attributes should be prohibited |
| 05:42 | <othermaciej> | btw if you click on the yes/no links you can see my methodology |
| 05:42 | <othermaciej> | which I guess I should document |
| 05:42 | <othermaciej> | I am using validator.nu to check for HTML5 and XHTML5 conformance |
| 05:42 | <othermaciej> | I am using validator.w3.org to check for conformance to declared doctype, if it is something other than HTML5 |
| 05:42 | <othermaciej> | I am counting only errors, not warnings, in both cases |
| 05:42 | <AryehGregor> | My methodology for bulk testing was: for domain in `cat top-domains-201003`; do echo -en "$domain:\t"; curl -Ss "http://validator.w3.org/check?uri=http://$domain"; | grep -o 'This document was successfully checked\|Errors found while checking this document\|This document can not be checked'; done |
| 05:43 | <othermaciej> | My goal here is detailed review of a fairly small number of sites, with the errors classified by hand |
| 05:43 | <AryehGregor> | Right. Makes sense for your purpose. |
| 05:43 | <othermaciej> | since in some cases, the validator reports errors that are not errors per spec, or misclassifies the nature of the error |
| 05:43 | <AryehGregor> | I was looking for a statistic, for an unrelated purpose. |
| 05:44 | <othermaciej> | hmmm |
| 05:44 | <othermaciej> | how do I add text that goes before the table of contents in MediaWiki? |
| 05:45 | <AryehGregor> | Just add it before the first section, the TOC is put before the first section by default. If you don't like the automatic TOC positioning, you can position it manually with __TOC__. |
| 05:45 | <othermaciej> | I see |
| 05:45 | AryehGregor | tries to figure out what his login is on the W3C wiki |
| 05:46 | <AryehGregor> | Hey, it does username autocompletion. I wonder who wrote that. |
| 05:47 | AryehGregor | figures out his username |
| 05:47 | <AryehGregor> | 1.12.0, yay. |
| 05:47 | <AryehGregor> | Any particular reason you used CamelCase for the page name? |
| 05:48 | <othermaciej> | it's the only thing I knew how to do |
| 05:49 | <othermaciej> | if I had my choice, I would call it "HTML5 Authoring Conformance Study" |
| 05:49 | <othermaciej> | or something like that |
| 05:49 | <othermaciej> | if you know how to fix it, that would be sweet |
| 05:49 | <othermaciej> | I just moved the TOC to where I want it |
| 05:49 | <AryehGregor> | Your choice is granted. |
| 05:50 | <AryehGregor> | MediaWiki doesn't require camel-case names. I'm told that's one of its major historical innovations, although it was well before my time. |
| 05:50 | <AryehGregor> | othermaciej, is it a bug in the validator that's flagging autocomplete in the validator, or the fact that it's on <input type=hidden>? |
| 05:51 | <othermaciej> | oh |
| 05:51 | <othermaciej> | is it always on input type=hidden? |
| 05:51 | <othermaciej> | is that a conformance error? |
| 05:52 | <othermaciej> | it does look like <input type=hidden autocomplete=off> is nonconforming |
| 05:53 | <AryehGregor> | It's on <select> in some cases. |
| 05:53 | <othermaciej> | is it disallowed on <select> too? |
| 05:53 | <AryehGregor> | Seems so. |
| 05:53 | <othermaciej> | looks like it is |
| 05:53 | <othermaciej> | mea culpa |
| 05:53 | <othermaciej> | not sure offhand if the spec should allow those |
| 05:54 | <othermaciej> | in the case of <select>, it seems like it would be useful, and in the case of <input type=hidden>, it seems harmless but not useful either |
| 05:55 | <othermaciej> | fixing it |
| 05:55 | <AryehGregor> | Do browsers autocomplete <select>? |
| 05:55 | <othermaciej> | I believe Safari may, in at least some cases |
| 05:57 | <othermaciej> | right now I'm classifying the rest of the errors on yahoo.com |
| 05:57 | <othermaciej> | if you want to do any of the others, feel free |
| 05:57 | <othermaciej> | it's interesting how few of the Alexa top 100 validate |
| 05:57 | <othermaciej> | I think wikipedia.org may be the only one that is HTML5 and validates |
| 05:57 | <dbgi> | if anyone needs a free shell on a really nice webserver for a website or whatever, send me a msg |
| 05:58 | <AryehGregor> | Well, that's because I wrote the current front page. :P |
| 05:58 | <othermaciej> | :-) |
| 05:58 | <AryehGregor> | Or, rather, fixed it up. |
| 05:58 | <AryehGregor> | Also because I poked the right people about getting validator bugs fixed. |
| 05:58 | <AryehGregor> | So, not really surprising. :P |
| 06:02 | <AryehGregor> | I did all the easy (short) ones. |
| 06:02 | <AryehGregor> | Let me try one or two of the big ones, then I'll go to bed. |
| 06:02 | <othermaciej> | cool, thans |
| 06:02 | <othermaciej> | *thanks |
| 06:03 | <othermaciej> | note that I'm only counting errors, not warnings |
| 06:03 | <othermaciej> | or info notes |
| 06:03 | <AryehGregor> | Right. |
| 06:04 | <othermaciej> | I am too lazy to find out which of the warnings are mandated by the spec |
| 06:04 | <othermaciej> | and which are just because the validator author thought they were a good idea |
| 06:09 | <othermaciej> | ok, finished yahoo.com |
| 06:09 | <AryehGregor> | I'm doing qq.com. |
| 06:10 | AryehGregor | is puzzled by "Required attributes missing on element style": <style type="text/css" media="screen">↩#ppIn |
| 06:10 | <AryehGregor> | What could that possibly mean? |
| 06:10 | <othermaciej> | I think that is the error you get when you have <style> outside <head> and it is not <style scoped> |
| 06:11 | <AryehGregor> | Aha. |
| 06:11 | <othermaciej> | I'm doing youtube |
| 06:11 | <othermaciej> | this exercise is less work than I initially expected, I may expand it to the top 20 plus the "honorable mention" and "HTML5 notable" sites that Sam mentioned on his blog |
| 06:12 | <othermaciej> | I am amused that not a single one of Google's Web properties in the top 100 validates |
| 06:12 | <othermaciej> | and many of them have huge numbers of errors |
| 06:12 | <othermaciej> | too bad the Web Standards Project no longer cares about that sort of thing |
| 06:12 | <AryehGregor> | They obviously don't care about validation at all, yeah. |
| 06:12 | <AryehGregor> | They care about interoperability in a practical sense only. |
| 06:12 | <AryehGregor> | I guess. |
| 06:13 | <othermaciej> | since Google folks are presumbly pretty smart about the Web, does this give evidence that validation is pointless? |
| 06:14 | <othermaciej> | or that validators are useful for a particular audience but others people/organizations may find it more productive not to validate |
| 06:14 | <AryehGregor> | You mean, you're thinking of validation as being a way to catch authoring errors from a pragmatic standpoint, and not a way to impress people with how standards-compliant you are? |
| 06:14 | <AryehGregor> | To be honest, that's a strange point of view to me. |
| 06:14 | <AryehGregor> | Validators are sometimes useful, it's true. |
| 06:15 | <AryehGregor> | But realistically, they're definitely much more annoying than useful, flagging all sorts of trivial things that work perfectly fine and rarely helping you with debugging. |
| 06:15 | <AryehGregor> | Sometimes they do, but not that often. |
| 06:15 | <AryehGregor> | At least in my experience. YMMV. |
| 06:18 | <othermaciej> | Should validators (and notions of document conformance) be changed so they are helpful more often than they are annoying? |
| 06:18 | <othermaciej> | C compiler warnings are often annoying but if you just blindly fix them all you will fix some real bugs |
| 06:18 | <othermaciej> | probably more than if you tried to review them one at a time |
| 06:18 | <AryehGregor> | If that's the goal, presentational attributes definitely need to be allowed, for starters. |
| 06:18 | <AryehGregor> | Many of the errors I'm seeing here are reasonable, though. |
| 06:19 | <AryehGregor> | But if that's the only goal of a validator, then there's no need for the spec to say what's valid. |
| 06:19 | <AryehGregor> | You can have competition between different error-checkers. |
| 06:19 | <othermaciej> | people have indeed raised that proposition |
| 06:20 | <othermaciej> | hsivonen says that it's useful for there to be at least a reasonable common base of errors reported, so you can switch validators without breaking your whole workflow |
| 06:20 | <AryehGregor> | It would also still be useful to retain a way of checking whether you're only using standard, interoperable functionality. |
| 06:20 | <othermaciej> | the one error that seems clearly bogus to me based on info so far is unescaped & in an attribute |
| 06:21 | AryehGregor | agrees with that |
| 06:21 | <othermaciej> | it seems like a huge waste of time to escape all those |
| 06:21 | <othermaciej> | I am also dubious about the value of banning presentational elements/attributes |
| 06:21 | <othermaciej> | but that seems less clearcut |
| 06:21 | <othermaciej> | most of these sites show only a tiny handful of uses which may well be an oversight, not a deliberate strategy |
| 06:21 | <othermaciej> | the main exception being google.com, which is clearly using presentational markup very deliberately |
| 06:22 | <AryehGregor> | If you leave the top 100 sites, you'll find a lot more deliberate presentational markup. |
| 06:22 | <AryehGregor> | Or just look at a random Wikipedia page's content (not the skin). |
| 06:23 | <othermaciej> | it does seem to me that presentational markup is a matter of taste, not unambiguously an "error" |
| 06:23 | <othermaciej> | I am ok with saying <i>foo <b> bar </i> baz </b> is an error |
| 06:24 | <othermaciej> | because it's almost certainly not going to give quite the result you intended, so it is probably a mistake |
| 06:24 | <othermaciej> | likewise with duplicate ids |
| 06:24 | <othermaciej> | but I don't see how use of the <u> element is in that same category |
| 06:24 | <AryehGregor> | It's in the same category as omitting alt from <img>. |
| 06:25 | <AryehGregor> | I.e., the spec bans it because of political pressure, not because it's not a rational thing for some authors to do. |
| 06:25 | <AryehGregor> | Anyone who thinks it's usually in authors' interest to give good alt text is smoking something. Good for blind users, yes; but most authors have a negligible number of blind users relative to the effort it would take to use alt text properly. |
| 06:25 | <AryehGregor> | But this is politically unacceptable to acknowledge in a spec, it seems to me. |
| 06:26 | <othermaciej> | some authors have legal or policy reasons to care about blind users disproportionate to their share of the audience |
| 06:27 | <AryehGregor> | Not most, though. |
| 06:27 | <othermaciej> | others (e.g. random using uploading Flickr photo or writing a GMail message to grandma) do not |
| 06:27 | <AryehGregor> | The requirement is unreasonable for the large majority of authors, from a rational/economic standpoint. |
| 06:27 | <othermaciej> | it's plausible as a legal requirement for governments and large corporations or charities |
| 06:28 | <AryehGregor> | Yes, but that's not most authors. |
| 06:28 | <AryehGregor> | It's a small minority. |
| 06:28 | <AryehGregor> | But the requirement in the spec is absolute. |
| 06:28 | <AryehGregor> | Banning presentational markup is similar. |
| 06:28 | <othermaciej> | by visit count it probably affects most content, by page count, no |
| 06:28 | <othermaciej> | see also: power law distribution |
| 06:29 | <othermaciej> | I'm not sure that banning presentational markup even has an accessibility benefit |
| 06:29 | <AryehGregor> | Your hypothesis suggests that major sites would reliably have good alt text. |
| 06:29 | <AryehGregor> | Or at least major competently-run sites would. |
| 06:29 | <AryehGregor> | Is this the case? I doubt it. |
| 06:30 | <othermaciej> | my hypothesis is that they have a legal/policy requirement, not that they are always attentive to it |
| 06:30 | <othermaciej> | for better or for worse, it's probably something they see as a cost of doing business, not an opportunity |
| 06:32 | <AryehGregor> | Nevertheless, it's not useful advice to the large majority of authors. Maybe if you weight by page views, but I doubt authors use validators proportional to their page views. |
| 06:32 | <AryehGregor> | It's not useful advice to the large majority of authors who are trying to check their work in a validator. |
| 06:32 | <AryehGregor> | So it's not useful if your goal is a lint-like tool. |
| 06:33 | <AryehGregor> | I see two major purposes in a validator: 1) Informing authors of possible mistakes. 2) Informing concerned users about how standards-compliant a site is (e.g., for clients who are interested in having a standards-based site for policy reasons). |
| 06:34 | <othermaciej> | are duplicate IDs a useful error to report? |
| 06:34 | <othermaciej> | it seems like (2) is circular as a reason to have more conformance requirements |
| 06:34 | <othermaciej> | if the only reason to have a standards conformance requirement is to report to concerned users that a site fails that requirement, then that in itself is not a very good reason |
| 06:35 | <AryehGregor> | (2) would suggest reporting things that suggest the page is using non-standard functionality, such as unrecognized elements or attributes, or <object>s containing Flash, etc. |
| 06:35 | <othermaciej> | 37 errors left to classify on YouTube... |
| 06:35 | <othermaciej> | <object>s containing Flash is something that no current validator will complain about |
| 06:35 | <AryehGregor> | By "standards-compliant" I meant "following de facto or de jure standards so as to behave interoperably in different clients". |
| 06:35 | <othermaciej> | I suspect making it a conformance error would mae lots of people mad |
| 06:35 | <AryehGregor> | I think they should. |
| 06:36 | <AryehGregor> | (complain, not be mad :) ) |
| 06:36 | <othermaciej> | as for unrecognized elements, it still seems circular to me to say that they should be nonstandard so that the validator can report that they are nonstandard |
| 06:36 | <othermaciej> | if the spec allowed arbitrary custom elements and attributes, then they wouldn't be nonstandard |
| 06:36 | <AryehGregor> | Then the spec would not be doing its job of specifying behavior that can be implemented interoperably. |
| 06:37 | <AryehGregor> | I don't care about standards for standards' sake, I care about ensuring interoperability. |
| 06:37 | <othermaciej> | saying that they should be nonstandard so a valid document doesn't accidentally rely on uninteroperable behavior seems reasonable |
| 06:37 | <othermaciej> | though that is an aid to the author too, not just vigilant users |
| 06:37 | <AryehGregor> | Yes. |
| 06:39 | <AryehGregor> | Finished qq.com. |
| 06:40 | <AryehGregor> | Lots of miscellaneous errors. It seems closer to what a typical site looks like. |
| 06:41 | <AryehGregor> | X-UA-compatible is another notable occurrence. |
| 06:42 | <AryehGregor> | Well, I guess only three sites have it |
| 06:42 | <AryehGregor> | . |
| 06:44 | <AryehGregor> | Okay, time for sleep. I'm going to be a wreck tomorrow. |
| 06:44 | <othermaciej> | ok done with youtube |
| 06:44 | <othermaciej> | thanks for the help |
| 07:42 | <othermaciej> | these results are really thrown off by the sheer number of Google Web properties that rank high in Alexa |
| 08:10 | <othermaciej> | wow, chromium.org is a disaster markup-wise: http://validator.nu/?doc=http%3A%2F%2Fwww.chromium.org%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full-aria.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5 |
| 10:19 | <jgraham> | othermaciej, AryehGregor: You know that hsivonen has code to collect and categorise validator errors, right? |
| 10:20 | <othermaciej> | jgraham: Sam Ruby made a script that I think parses the XML output of the validator, but the current validator misclassifies some of its own errors |
| 10:20 | <othermaciej> | jgraham: so I'm finding I can't get good quality results without at least a bit of human judgment |
| 10:20 | <jgraham> | OK |
| 10:21 | <jgraham> | Duplicsate IDs seem like a real and obvious error btw |
| 10:22 | <jgraham> | (because they are easy to add by accident and can have unexpected consequences if you don't realise that you have made the error) |
| 10:27 | <othermaciej> | I do think duplicate IDs are a real error that should be reported, yes |
| 10:27 | <othermaciej> | I am not sure that Sam thinks otherwise, despite his nominal stance that all document conformance requirements should be removed |
| 10:28 | <othermaciej> | I think he actually believes that some should be removed, but does not want to do the work to describe which ones |
| 10:38 | <othermaciej> | I am really curious how two sites ended up in the alexa top 100 that are unreachable |
| 10:39 | <gavin> | heh |
| 10:43 | <othermaciej> | kinda implies that there is a major flaw in how they gather their traffic stats |
| 10:51 | <othermaciej> | Philip`: that's neat data, how fresh is it? |
| 10:52 | <Philip`> | "The source data is 131,072 randomly-selected HTTP URIs from the Open Directory Project, downloaded on 2008-02-26." |
| 10:52 | othermaciej | would guess the HTML5 doctype is now more popular than the HTML2 doctype |
| 10:52 | <othermaciej> | though that might be overly optimistic |
| 10:52 | <othermaciej> | might not be in HTML 3.2 territory yet |
| 10:53 | <othermaciej> | wow, nearly half of pages have no doctype? (or at least did at time of study) |
| 10:54 | <Philip`> | http://www.pcmech.com/article/the-mysterious-1e100-net/ |
| 10:54 | <Philip`> | Sounds like that one's a Google CDN of some kind |
| 10:54 | <Philip`> | hence getting lots of traffic, but not being an actual web site |
| 10:55 | <othermaciej> | oh, hahaha |
| 10:56 | <othermaciej> | I should have spotted the pun |
| 10:58 | <othermaciej> | I wonder what bp.blogspot.com is then |
| 10:59 | <othermaciej> | ah, another subdomain-only google domain |
| 10:59 | <othermaciej> | http://1.bp.blogspot.com/ |
| 11:03 | <Philip`> | I wouldn't expect the number of no-doctype pages to change much |
| 11:03 | <Philip`> | since the number of people who are lazy and/or ignorant of the problems of quirks mode is unlikely to change much |
| 11:04 | <Philip`> | so they'll be creating the same proportion of no-doctype new pages |
| 11:05 | <Philip`> | (When people hear about the HTML5 doctype that might overcome laziness, but that'll take years) |
| 11:06 | <othermaciej> | yeah I wouldn't expect no-doctype to change |
| 11:06 | <othermaciej> | and I would expect attrition rate of truly ancient doctypes to be quite slow |
| 11:06 | <othermaciej> | what I'm expecting is use of the HTML5 doctype may have gone up |
| 11:07 | <othermaciej> | I think none of the alexa top 100 sites that use it were doing so 2 years ago |
| 11:09 | <othermaciej> | most ironic non-use of HTML5 doctype: http://www.youtube.com/html5 |
| 11:10 | <othermaciej> | no wait, I lie, the truly most ironic non-use is http://www.w3.org/TR/html5/ |
| 11:15 | <MikeSmith> | in a sane world, authors wouldn't have to worry about including a doctype and would not be seen as lazy if they just omitted it |
| 11:15 | <othermaciej> | it would be good if no special talisman is needed |
| 11:15 | <MikeSmith> | and the issue of what doctype the HTML5 TR should have would be a non-issue |
| 11:16 | <othermaciej> | I do feel like triggering standards mode is a benefit that is worth the cost of "<!DOCTYPE html>" |
| 11:16 | <MikeSmith> | yeah, absolutely |
| 11:16 | <othermaciej> | it would be better if we could get rid of even the vestigial remainder |
| 11:16 | <MikeSmith> | indeed |
| 11:17 | <othermaciej> | but it's probably not possible, due to the mass of content in quirks mode (and therefore presumably authored to quirks mode) |
| 11:56 | <annevk> | we could invent a mime type that takes the pain away |
| 11:56 | <annevk> | but that's prolly not worth it |
| 11:56 | <annevk> | text/htmls |
| 12:20 | <othermaciej> | that just sounds like more pain |
| 12:20 | <annevk> | text/pain |
| 12:21 | <annevk> | gonna be a hit |
| 12:42 | annevk | is having fun on twitter |
| 12:43 | annevk | should really do something useful; like writing the presentation he has to give tomorrow |
| 12:48 | <MikeSmith> | annevk: where are you presenting? |
| 12:51 | <annevk> | somewhere I can cycle towards |
| 12:51 | <annevk> | I think it's a first |
| 12:52 | <annevk> | well, apart from school and university |
| 12:52 | <annevk> | ironically, and perhaps unsurprisingly, this is at university |
| 12:52 | <annevk> | but I'm the teacher now, or something :p |
| 13:08 | <othermaciej> | Philip`: I wish there were a count of the number of pages using xmlns attributes instead of just count of attributes |
| 13:08 | <Philip`> | othermaciej: Which file are you looking at? |
| 13:09 | <othermaciej> | oops, my paste failed |
| 13:09 | <othermaciej> | http://philip.html5.org/data/xmlns-bindings.txt |
| 13:09 | <othermaciej> | actually, I'm not even sure what those counts are |
| 13:09 | <othermaciej> | are they counts of the number of times that prefix declaration appeared, or the number of pages on which it appeared? |
| 13:09 | <Philip`> | "Counts are the number of pages with that attribute name+value." |
| 13:10 | <Philip`> | so number of pages |
| 13:10 | <Philip`> | http://philip.html5.org/data/xmlns-attributes.txt is similar but newer |
| 13:11 | <Philip`> | (though it includes non-HTML pages too, I think) |
| 13:12 | <othermaciej> | what I'm curious about that I don't think I can get from this output is the number of pages that contain at least one xmlns attribute |
| 13:12 | <othermaciej> | in your older study, 79% of the occurrences of namespace declarations had "microsoft" in the namespace URI |
| 13:12 | <Philip`> | Do you mean xmlns:* (i.e. not counting xmlns="http://www.w3.org/1999/xhtml";)? |
| 13:12 | <othermaciej> | that seems less likely with the new data |
| 13:13 | <othermaciej> | yeah xmlns:* |
| 13:14 | <othermaciej> | (also of potential interest would be a separate count of xmlns= that are neither the xhtml namespace URI nor empty, if there are nay such) |
| 13:14 | <Philip`> | I could upload my list of all (url, element-name, attribute-name-which-begins-with-"xmlns", attribute-value) from the dotbot data so you can process it yourself, if you want |
| 13:16 | <othermaciej> | that would be neat |
| 13:16 | <Philip`> | http://philip.html5.org/data/xmlns-attributes-raw.txt.bz2 (~5MB) |
| 13:17 | <Philip`> | (with all the usual caveats about sample selections and bias and bugs and so on) |
| 13:25 | <othermaciej> | $ grep 'xmlns:' xmlns-attributes-raw.txt | sed -e 's/ *//g;' | sort | uniq | xwc -l |
| 13:25 | <othermaciej> | 18718 |
| 13:26 | <Philip`> | Your sed looks wrong |
| 13:26 | <Philip`> | They're tab-separated fields |
| 13:26 | <othermaciej> | I used a tab |
| 13:26 | <othermaciej> | (use ^V to enter a literal tab) |
| 13:27 | <othermaciej> | by that count, 4.4% of pages contain an XML namespace prefix declaration |
| 13:27 | <Philip`> | Oh, it looks like spaces in IRC :-) |
| 13:27 | <Philip`> | (I'd use "cut -f1" to extract the first field instead) |
| 13:27 | <othermaciej> | I checked that it stripped all fields but the first |
| 13:28 | <othermaciej> | noted! |
| 13:28 | <othermaciej> | cut -f1 gives a different result so I may have made a mistake |
| 13:28 | <Philip`> | I get 18718 if I *don't* do any sed/cut |
| 13:29 | <othermaciej> | my sed line is wrong |
| 13:29 | <othermaciej> | (it doesn't do nothing, but it does do the stripping wrong |
| 13:29 | <Philip`> | Oh, good point |
| 13:29 | <othermaciej> | what I wanted was sed -e 's/ .*//g;', except that cut is better |
| 13:29 | <Philip`> | It's just stripping out the tabs, I guess |
| 13:30 | <othermaciej> | so 7601 |
| 13:30 | <othermaciej> | so 1.8% of pages include at least one XML Namespace prefix declaration |
| 13:31 | <othermaciej> | Is it ok if I put a link to the raw data in the HTML WG wiki? |
| 13:31 | <Philip`> | Sure |
| 13:32 | <Philip`> | Note that quite a few of these pages appear to be RSS feeds |
| 13:32 | <Philip`> | which annoyingly happen to be included in the data set |
| 13:33 | Philip` | doesn't claim that it is high-quality data |
| 13:33 | <othermaciej> | 2476 pages have an xml namespace prefix declaration that has "microsoft" in the namespace URI |
| 13:35 | <othermaciej> | $ grep 'xmlns:' xmlns-attributes-raw.txt | egrep -v 'rss|feed' | cut -f1 | sort | uniq | xwc -l |
| 13:35 | <othermaciej> | 6853 |
| 13:35 | <othermaciej> | $ grep 'xmlns:.*microsoft' xmlns-attributes-raw.txt | egrep -v 'rss|feed' | cut -f1 | sort | uniq | xwc -l |
| 13:35 | <othermaciej> | 2458 |
| 13:36 | <othermaciej> | so more like 1.6%, and 36% of those are Microsoft namespace URIs |
| 13:58 | <MikeSmith> | othermaciej: the autocomplete=off instances on the facebook homepage are not conformant; autocomplete is explicitly not allowed on input/@type=hidden |
| 13:58 | <MikeSmith> | http://dev.w3.org/html5/spec/forms.html#hidden-state |
| 13:59 | <othermaciej> | MikeSmith: I know - I forgot to close the validator bug when I found that out |
| 13:59 | <MikeSmith> | ok, I'll close it myself now |
| 14:18 | <othermaciej> | MikeSmith: question: do you understand the error in the doctype reported here? http://validator.nu/?doc=http%3A%2F%2Ffacebook.com%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F |
| 14:18 | <othermaciej> | MikeSmith: it seems to be complaining about the newline - I think |
| 14:18 | <othermaciej> | is that actually noncomforming? |
| 14:20 | <othermaciej> | ok, looks like newlines in the doctype are indeed disallowed in HTML5 |
| 14:20 | <othermaciej> | is that also true in XML, or SGML? |
| 14:23 | <TabAtkins> | AryehGregor: When talking about blind users, don't forget the ones that *are* measurably important to all authors, the search engines. |
| 14:24 | <TabAtkins> | AryehGregor: (That is, ironically, why I have to keep *removing* alt text from my company's site, because the idiot SEO people just keep cramming keywords into them.) |
| 14:24 | <jgraham> | othermaciej: Newlinwa in doctype appear to be OK per XML |
| 14:24 | <jgraham> | wtf |
| 14:24 | <jgraham> | Newlines |
| 14:25 | <othermaciej> | I'm not sure why HTML5 only allows spaces as the whitespace in doctypes |
| 14:25 | <othermaciej> | (at least that's what it appears to do) |
| 14:36 | <MikeSmith> | othermaciej: as far as the code that's emitting that error message, it's in the htmlparser code, so I have less insight into to that |
| 14:36 | <MikeSmith> | I'm also have no idea why it's disallowed |
| 14:36 | <MikeSmith> | I think it may just be a mistake |
| 14:37 | <Philip`> | othermaciej: Why do you think the newline has any effect? |
| 14:37 | <Philip`> | All whitespace should be handled the same, and I don't see any different behaviour here |
| 14:38 | <othermaciej> | Philip`: this is an error: http://validator.nu/?doc=http%3A%2F%2Ffacebook.com%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F |
| 14:38 | <othermaciej> | Philip`: but this is not: http://validator.nu/?doc=http%3A%2F%2Fwww.msn.com%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5&laxtype=yes |
| 14:39 | <othermaciej> | hmm, the error goes away if I change the parser to HTML5 |
| 14:39 | <othermaciej> | mea culpa |
| 14:40 | <Philip`> | I think the validator is consistent across sites, it's just got occasionally confusing modes |
| 14:41 | <MikeSmith> | so that error was coming from it being parsed by the XML parser? |
| 15:21 | <othermaciej> | MikeSmith: I think using the HTML4 parser instead of the HTML5 parser makes XHTML doctypes an error |
| 15:29 | <othermaciej> | what's the third error here about: http://validator.nu/?doc=http%3A%2F%2Fwordpress.com%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full-aria.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5 |
| 15:29 | <othermaciej> | (it's a <script> without src, but it's also non-empty) |
| 15:30 | <othermaciej> | I wish it would say what attribute it thinks is missing! |
| 15:31 | <annevk> | if you specify charset you must specify src I think |
| 15:31 | <Philip`> | "The charset attribute gives the character encoding of the external script resource. The attribute must not be specified if the src attribute is not present." |
| 15:32 | <othermaciej> | ah, I see |
| 15:35 | <MikeSmith> | othermaciej: In my workspace, I have a fix for the problem of v.nu not reporting the names of missing attributes |
| 15:36 | <MikeSmith> | but I need to make some changes to it before committing it |
| 15:36 | <othermaciej> | I guess it's pointless to specify charset without src |
| 15:36 | <Philip`> | It should have no effect, and is confusing because people reading the markup might expect it to have an effect |
| 15:37 | <MikeSmith> | hmm, that may be a bug, though |
| 15:37 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fwordpress.com%2F does not report it as an error |
| 15:38 | <othermaciej> | Is it trying to apply HTML5 validation? |
| 15:38 | <othermaciej> | that error only shows up if you force HTML5 mode |
| 15:38 | <Philip`> | (and preventing confusion is a common part of the rationale for conformance requirements) |
| 15:39 | <MikeSmith> | the fact that it's not reported as an error by the qa-dev v.nu instance appears to be that I have a bug in my workspace code |
| 15:39 | <Philip`> | MikeSmith: "XHTML 1.0 Transitional doctype seen. [...] Using the schema for HTML 4.01 Transitional + IRI / XHTML 1.0 Transitional + IRI." |
| 15:39 | <MikeSmith> | oh, OK |
| 15:40 | <MikeSmith> | http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fwordpress.com%2F&schema=http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fhtml5full-aria.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=html5 |
| 15:40 | <MikeSmith> | Error: Element script is missing required attribute src. |
| 15:40 | <MikeSmith> | I really need to get that fix committed |
| 15:41 | <Philip`> | That's still a far less helpful error than saying it's required because of the charset |
| 15:41 | <Philip`> | People will think they have to add a src, they won't think they have to remove the charset |
| 15:42 | <Dashiva> | I agree |
| 15:42 | <Philip`> | I'm only saying that because I don't have to implement it, of course |
| 15:42 | <Dashiva> | It should say something like "charset attribute only applies to external scripts" or something. |
| 15:43 | <MikeSmith> | well, this is fundamental problem with grammar-based constraint checking |
| 15:43 | <MikeSmith> | we could move the constraint check for this case to the assertions-checking code, where we have precise control over the error message |
| 15:43 | <Dashiva> | Can't you... invert the constraint or something? |
| 15:43 | <MikeSmith> | but if we do this check using the RelaxNG schema, we have no real control over the error that's reported |
| 15:43 | <annevk> | it should prolly say "remove the charset attribute" |
| 15:43 | <Dashiva> | Instead of saying charset requires src, say !src requires !charset |
| 15:44 | <Dashiva> | (Disclaimer: I don't know relaxng) |
| 15:44 | <MikeSmith> | Dashiva: if we move this out of the schema, then anybody using the schema only (without also at least using the associated Schematron assertions) is not going to see any error message at all for this |
| 15:45 | <Dashiva> | So the schema doesn't allow negative assertions like that one? |
| 15:45 | <MikeSmith> | Dashiva: no, we can't really invert the constraint in the scheam |
| 15:45 | <MikeSmith> | Dashiva: no, it doesn't |
| 15:46 | <Dashiva> | I don't think optimizing for solutions that are known to be fundamentally lacking is a good idea, though |
| 15:46 | <MikeSmith> | this is not just a case for charset, it's the same case for defer and async |
| 15:46 | <MikeSmith> | Dashiva: you are preaching to the choir on that |
| 15:47 | <Philip`> | Who is the anybody using the schema only? |
| 15:47 | <MikeSmith> | see my recent messages to www-tag, if you care to |
| 15:47 | <MikeSmith> | Philip`: the availability of the schema risks people actually using it alone |
| 15:47 | <Philip`> | i.e. are they hypothetical persons, or real practical implementations? |
| 15:47 | <MikeSmith> | people will use it alone |
| 15:47 | <MikeSmith> | this is not about implementations |
| 15:48 | <MikeSmith> | people can grab the schema and use it with Jing or whatever other RelaxNG validation tool they want |
| 15:48 | <Dashiva> | Well, aren't these errors here mainly harmless? |
| 15:48 | <MikeSmith> | use it from the command line |
| 15:48 | <Dashiva> | So it doesn't matter if someone aiming for mediocrity doesn't get the warnings |
| 15:49 | <MikeSmith> | Dashiva: no a particularly helpful way to describe it |
| 15:49 | <MikeSmith> | the schema is useful on its own as a way to guide context-sensitive editing |
| 15:49 | <MikeSmith> | that is, integrated into editing apps |
| 15:50 | <MikeSmith> | someone can right now take that schema and use it to edit HTML5 documents in Emacs, for example |
| 15:50 | <MikeSmith> | in nxml-mode |
| 15:50 | <MikeSmith> | that is not a case of anybody aiming for mediocrity |
| 15:50 | <MikeSmith> | ask hober |
| 15:50 | <Dashiva> | Why wouldn't they include the schematron portions as well? |
| 15:51 | <MikeSmith> | Dashiva: because nxml-mode does not do Schematron checking |
| 15:52 | <MikeSmith> | that does not mean it's useless |
| 15:52 | <Dashiva> | I didn't say it was useless, I said it was mediocre |
| 15:52 | <MikeSmith> | whatever |
| 15:52 | <Philip`> | I imagine RNG makes it possible to determine what is the next permitted token given an incomplete document, whereas Schematron doesn't |
| 15:52 | <Philip`> | so the latter isn't much good for auto-complete |
| 15:53 | <MikeSmith> | right |
| 15:53 | <MikeSmith> | all that Schematron does is test XPath expressions |
| 15:53 | <Philip`> | Can they be Turing-complete expressions? |
| 15:53 | <othermaciej> | so there's really no way to say an attribute is conditionally allowed based on presence of another? |
| 15:54 | <MikeSmith> | othermaciej: that is in fact what the schema currently says |
| 15:54 | <Dashiva> | I also don't see how _absense_ of src is going to lead to a benefit in autocomplete |
| 15:54 | <MikeSmith> | it says, charset is allowed if the src attribute is specific |
| 15:54 | <MikeSmith> | Dashiva: true |
| 15:54 | <othermaciej> | I see, so it's just the error message that is bad |
| 15:54 | <MikeSmith> | s/specific/specified/ |
| 15:54 | <othermaciej> | it should say that charset is disallowed rather than src is missing |
| 15:55 | <othermaciej> | it seems like that would be the more natural way to express the constraint |
| 15:55 | Philip` | wonders if there's a subset of Schematron that allows the permitted next characters to be computable, while still being more expressive than RNG grammars |
| 15:55 | <MikeSmith> | othermaciej: as I said, I don't think we can have it report that with just the schema. we need to have it reported in the assertions code |
| 15:56 | <MikeSmith> | and if we keep it in the schema, then we get two errors reported |
| 15:56 | <MikeSmith> | Dashiva: this may indeed by a case where we can remove it from the schema with causing harm |
| 15:56 | <Dashiva> | Philip`: Surely it should be possible to expand RNG to handle absense of attributes too |
| 15:56 | <othermaciej> | I guess it is a problem of the schema engine sucking |
| 15:56 | <MikeSmith> | I hope we can remove it, personally |
| 15:57 | <MikeSmith> | this is a general deficiency in all grammar-based validation mechanisms that I am aware of |
| 15:57 | <othermaciej> | if it doesn't get fixed, then it's probably better to prioritize quality of error messages over usability of the schema for alternate purposes |
| 15:57 | <MikeSmith> | othermaciej: agreed |
| 15:58 | <MikeSmith> | othermaciej: again, see my comments about this that I posted in replies to DanC on the TAG mailing list |
| 15:58 | <MikeSmith> | this is one of the main reasons I don't want to have the HTML WG publish that schema |
| 15:58 | <MikeSmith> | me and others |
| 15:59 | <Philip`> | Dashiva: I expect negation is fundamentally incompatible with the theoretical model used by RNG |
| 15:59 | <Philip`> | (I don't know that's true, but it would explain why they don't have negation) |
| 16:01 | <Philip`> | In any case, if the grammar allows <script> and <script src charset> and the input is <script src> then it's easy to tell the input doesn't match the grammar, but there's no general correct way to decide which specific part of the grammar it's not matching |
| 16:02 | <Philip`> | so implementations have to make some arbitrary choice of which error to report, and in some cases that won't be ideal |
| 16:02 | <othermaciej> | Microsoft's homepage seems to return different content to http://validator.w3.org/ and http://validator.nu/ , even when forcing HTML5 mode in both |
| 16:03 | <othermaciej> | hmm, it seems to have stopped doing so |
| 16:03 | <MikeSmith> | Philip`: the choice that Jing makes (and likely any other RelaxNG implementation makes) is to report anything that is required but missing |
| 16:05 | <Philip`> | MikeSmith: If the grammar allows <foo bar> and <foo baz> and you write <foo>, then what does it report? |
| 16:06 | <MikeSmith> | it depends on the implementation |
| 16:06 | <MikeSmith> | the trunk of jing reports "required attributes missing" |
| 16:06 | <Philip`> | Ah |
| 16:06 | <MikeSmith> | you see why now, I think |
| 16:06 | <MikeSmith> | but the patched jing in my workspace reports something different |
| 16:07 | <MikeSmith> | hang on, I will get a URL |
| 16:07 | <MikeSmith> | http://lists.w3.org/Archives/Public/www-archive/2010Jan/0077.html |
| 16:08 | <MikeSmith> | "Element object is missing one or more of the following attributes: data type" |
| 16:08 | <Philip`> | Ah, right |
| 16:13 | <Philip`> | Validator.nu ought to save the error messages reported for each page, and the diffs between versions of a URL that are validated at least twice in quick succession |
| 16:14 | <Philip`> | and feed that into some magic AI algorithm that can determine the most frequent markup fix associated with each validation error |
| 16:14 | <Philip`> | and use that to suggest the correct fix to future users |
| 16:14 | <MikeSmith> | seriously, we should eventually have something like that |
| 16:15 | <Philip`> | If the magic AI algorithm was replaced by a person, then it could perhaps work |
| 16:15 | <MikeSmith> | heh |
| 16:15 | <MikeSmith> | yeah |
| 16:15 | <Philip`> | and if the saving of messages and pages was replaced by something that doesn't violate the privacy policy |
| 16:16 | <MikeSmith> | well, anybody who wanted to experiment with trying it could implement their own checker on top of the v.nu API |
| 16:16 | <MikeSmith> | with their own privacy policy |
| 16:16 | <Philip`> | Maybe it wouldn't be too hard for someone to validate a load of existing pages and check the results, and write a suite of test cases that include the markup error and the best guess at a fix and a human-readable description of the issue |
| 16:17 | <Philip`> | and then validators can try to find heuristics that get a reasonable match to the expected descriptions/fixes for those cases |
| 16:17 | <Philip`> | s/validators/validator developers/ |
| 16:17 | <AryehGregor> | othermaciej, I assume that 1e100.net and the other don't have anything at the domain name itself, only on subdomains. |
| 16:17 | <othermaciej> | AryehGregor: that appears to be the case, yes |
| 16:18 | <Dashiva> | http://lists.w3.org/Archives/Public/public-html/2010Mar/0468.html |
| 16:18 | <Dashiva> | Does this message actually say anything? |
| 16:23 | <Philip`> | I think it says that we shouldn't be using Bugzilla for everything, and should have a different mechanism for higher-level issues |
| 16:24 | <Philip`> | but it says it in too polite a way, which waters down any meaning in the message |
| 16:24 | <Dashiva> | I guess my formulation of the question was a bit harsh. |
| 16:26 | <Dashiva> | But it seems to say things we already know and suggest things we already do. |
| 16:26 | <Philip`> | It's just a different tone to the usual focused directness on technical mailing lists |
| 16:27 | <Philip`> | The thing we already do is expect everything to be put into a Bugzilla bug |
| 16:28 | <Dashiva> | And use an issue tracker for larger issues |
| 16:29 | <Philip`> | and it seems to say we perhaps shouldn't do that, we should just use it for breaking down big problems into smaller ones and we need a different way of managing big issues |
| 16:29 | <Philip`> | The process requires use of the bug tracker before the issue tracker |
| 16:31 | <Dashiva> | That's a formality required to establish whether it's a large issue or not |
| 16:32 | <AryehGregor> | So, I have two spec-related goals today: ask the W3C validator team if we could work out some way for HTML5 to validate with an obsolete-but-conforming doctype; and post to whatwg arguing that presentational elements/attributes (at least some) should be obsolete but conforming instead of non-conforming. |
| 16:32 | <AryehGregor> | Dashiva, she's using "large" in the sense of "encompassing a broad topic", not "important". |
| 16:32 | <Philip`> | Dashiva: It might be a formality that makes it hard to address certain problems |
| 16:33 | <AryehGregor> | She makes a perfectly valid point: there is no way to argue about high-level, broad issues in the HTMLWG. |
| 16:33 | <AryehGregor> | This is by design, as far as I can tell. |
| 16:33 | <Dashiva> | Apart from the mailing list itself |
| 16:33 | <Philip`> | (since it might not be possible to express the problem as "a clear statement of a single problem with the spec") |
| 16:33 | <Dashiva> | You only need the tracking when you want to force a decision |
| 16:33 | <AryehGregor> | The mailing list lets you argue, fine, but it doesn't give you an avenue to get the spec changed, unless you can convince the editor. |
| 16:34 | <Dashiva> | But you can't change the spec in a high-level, broad way |
| 16:34 | <Dashiva> | You have to break it down into actual changes |
| 16:34 | <AryehGregor> | The only thing you can do is target one small issue and hope that the chairs' decision has larger-scale implications that the editor will choose to follow, as happened with splitting up the spec after the microdata decision. |
| 16:34 | <Dashiva> | It's fine to _argue_ high-level, but the text has to be written for specifics in the end |
| 16:35 | <AryehGregor> | In principle, we could permit Change Proposals that ask the editor to do something on a very high level, like "Try harder to align with other established specs" or something. We don't allow that (I think for good reason), but we could. |
| 16:35 | <othermaciej> | all right, I have everything but the detailed error breakdown added for all the sites to http://www.w3.org/html/wg/wiki/HTML5_Authoring_Conformance_Study |
| 16:36 | <othermaciej> | many sites still need the detailed breakdown though |
| 16:36 | <Dashiva> | High-level changes like that are unlikely to succeed, since nobody agrees 100% with the editor |
| 16:36 | <Dashiva> | So we'll just end up going back a second time and fixing all the little pieces... |
| 16:38 | <AryehGregor> | Dashiva, right. That's why we shouldn't allow such changes. But we could allow them in principle anyway, and have the editor ask the chairs for clarification on specifics, say. |
| 16:38 | <othermaciej> | There's two ways in which an issue can be "large" |
| 16:38 | <othermaciej> | one is requiring a large diff to the spec, even though it can be stated relatively succinctly |
| 16:39 | <othermaciej> | that seems fine as a bug, though if it gets rejected, writing the Change Proposal will be potentially a lot of work |
| 16:39 | <othermaciej> | another is that it has many subproblems |
| 16:39 | <othermaciej> | for that, I would say the only good tools we have for breaking such issues down are informal ones (mailing list discussion, wikis, etc) |
| 16:41 | <othermaciej> | ideally we shouldn't have issues at this point that they are so complicated that they need extensive work to break them down before they can be processed, but yet are so critical that they must be addressed before Last Call |
| 16:41 | <othermaciej> | because we're supposed to be trying to converge right now |
| 16:41 | <Dashiva> | supposed to :) |
| 16:43 | <MikeSmith> | AryehGregor: about "ask the W3C validator team if we could work out some way for HTML5 to validate with an obsolete-but-conforming doctype" |
| 16:43 | AryehGregor | waits with bated breath |
| 16:44 | Dashiva | admires AryehGregor's spelling |
| 16:44 | <othermaciej> | AryehGregor: can't you do that using the drop-down on the validator page? |
| 16:44 | <MikeSmith> | part the way is towards that is for users to first explicitly choose HTML5 validation |
| 16:44 | <Philip`> | <meta http-equiv="X-UA-Compatible" content="w3validator=5"> |
| 16:44 | <othermaciej> | under "More Options" |
| 16:44 | Philip` | can't remember whether the syntax as implemented in IE requires you to use a number or not |
| 16:44 | <Philip`> | (and of course it's undocumented) |
| 16:45 | <Philip`> | (and of course Chrome Frame implements it completely differently) |
| 16:45 | <AryehGregor> | othermaciej, sure, but I would like it to be autodetected correctly. People will check if it passes and say "Oh, Wikipedia uses invalid markup", not "Oh, it must be using HTML5 with an obsolete but conforming doctype, let me manually choose HTML5 and see if it validates when I do that." |
| 16:45 | <MikeSmith> | if a document has an HTML4 doctype and it's validate HTML4 and you don't ask the W3C validator to validate it as HTML5, then it's going to validate it as HTML4 |
| 16:45 | <AryehGregor> | s/Wikipedia/MediaWiki/ too. |
| 16:46 | <othermaciej> | AryehGregor: do you want it to try HTML4 validation first and then HTML5 if there's an error? |
| 16:46 | <MikeSmith> | AryehGregor: they odds of the W3C validator automatically switching to checking invalid HTML4 documents as HTML5 are extremely low |
| 16:46 | <othermaciej> | (assuming it's an HTML4 doctype) |
| 16:46 | <AryehGregor> | othermaciej, that was my first thought, but MikeSmith pointed out that that would mean it would check HTML5 an awful lot pointlessly. |
| 16:47 | <othermaciej> | AryehGregor: not only that, but it would not be a good change for people who actually do want to validate HTML4 |
| 16:47 | <MikeSmith> | we might be able to get to the validator to prompt users and ask them if they want to re-validate a doc as HTML5 |
| 16:47 | <AryehGregor> | MikeSmith, I'm currently thinking that perhaps it could be validated as HTML5 if 1) it has an XHTML 1.1 doctype, and 2) it has no xmlns attribute on the <html> element. Kind of a hack, but unlikely to be disruptive. Such documents cannot be valid XHTML 1.1. In case it *was* meant to be an XHTML 1.1 document, a note can be output explaining the situation and saying to add a correct xmlns if you really want XHTML 1.1. |
| 16:47 | <AryehGregor> | (I assume XHTML 1.1 still requires xmlns, like XHTML 1.0.) |
| 16:47 | <MikeSmith> | othermaciej: yeah, it would mean that every invalid HTML4 doc would get checked twice as many times as it is now |
| 16:48 | <MikeSmith> | which would not seem like a particularly good idea |
| 16:48 | <MikeSmith> | AryehGregor: doing some kind of heuristic checks like that might be acceptable |
| 16:48 | <Dashiva> | AryehGregor: Who would create an XHTML 1.1 document without xmlns? |
| 16:49 | <AryehGregor> | Dashiva, they wouldn't, so it must be HTML5 with a conforming but obsolete doctype. |
| 16:49 | <AryehGregor> | That's the point. :) |
| 16:49 | <Dashiva> | But why would the page exist in the first place? |
| 16:49 | <AryehGregor> | Currently MediaWiki uses XHTML 1.0 Strict, but XHTML 1.1 is less common, so would be a better choice. |
| 16:49 | <AryehGregor> | Because it can't use <!DOCTYPE html> because it wants to be well-formed XML and needs to have entity declarations. |
| 16:50 | <AryehGregor> | It's either that or try to get rid of every single and whatever, which is horribly error-prone. |
| 16:50 | <othermaciej> | do browsers give html entities under the XHTM 1.1 doctype? |
| 16:50 | <AryehGregor> | I'd have to test that. If not, I could stick with XHTML 1.0 Strict. |
| 16:50 | <Dashiva> | So it's actually non-XHTML XML with an entity hack |
| 16:51 | <AryehGregor> | It's HTML5 that's also well-formed XML, is the idea, yes. |
| 16:52 | <Philip`> | Given that people are going to process it with XML tools, it seems bad to not have the XHTML xmlns |
| 16:52 | <Dashiva> | They'll process it with generic XML tools that don't care about namespaces, I bet :) |
| 16:52 | <MikeSmith> | I am personally not interesting at all in putting any more time and energy and money into further integrating HTML5 checking into the existing W3C validator.. good money after bad, and all that .. what we need to do instead is get a production instance of the HTML5 running on www.w3.org, and start to do promotion of that, and awareness-raiwing about what it's meant to be used for |
| 16:52 | <AryehGregor> | Correct. |
| 16:52 | <AryehGregor> | Just basic parsers. |
| 16:52 | <Philip`> | It'll also be harder for them to switch their tools to a proper HTML5 parser (which does give namespaces) |
| 16:53 | <AryehGregor> | MikeSmith, I can see that makes sense from your point of view, but from my point of view, it's important that MediaWiki and Wikipedia be perceived as standards-compliant. Web standards are part of Wikimedia's mission and something I care about, and they need what PR they can get. |
| 16:53 | <MikeSmith> | AryehGregor: well, they are not standards-compliant |
| 16:53 | <AryehGregor> | In what way are they not? |
| 16:53 | <MikeSmith> | so you have a conflicting goal |
| 16:54 | <MikeSmith> | HTML5 is not a standard |
| 16:54 | <AryehGregor> | Draft-standard-compliant. |
| 16:54 | <AryehGregor> | I don't buy the W3C's insistence on glacial progression of standards along a formal track. |
| 16:54 | <MikeSmith> | geez |
| 16:54 | <MikeSmith> | the W3C is me, man |
| 16:54 | <MikeSmith> | me |
| 16:55 | <othermaciej> | if you want to get really technical, nothing the w3c publishes is a "standard" |
| 16:55 | <MikeSmith> | and other people |
| 16:55 | <AryehGregor> | :P |
| 16:55 | <MikeSmith> | AryehGregor: it is not a faceless blob of idiocy |
| 16:55 | <AryehGregor> | Draft standards that are interoperably implemented have pretty much all the benefits of actual standards, and it's not reasonable to avoid using them just because some totally unrelated features that happen to be in the same spec are not finalized yet. |
| 16:56 | <AryehGregor> | othermaciej, I think the W3C publishes standards in the dictionary sense of that term. |
| 16:56 | <AryehGregor> | Actually, HTML5 is a de facto standard at least, no matter what (at least the parts Wikipedia would bother using). |
| 16:56 | <Philip`> | othermaciej: plh said they're standards, in http://www.w3.org/QA/2009/05/_watching_the_google_io.html |
| 16:56 | <Philip`> | (comments) |
| 16:56 | <othermaciej> | I guess it's fair to say HTML5 is a conspicuous object (as a banner) formerly carried at the top of a pole and used to mark a rallying point especially in battle or to serve as an emblem |
| 16:58 | <AryehGregor> | It's that, too. |
| 16:59 | <AryehGregor> | Anyway, the WHATWG calls HTML5 a Draft Standard. |
| 16:59 | <AryehGregor> | Good enough for me. |
| 16:59 | <Philip`> | It started calling it a Standard after the aforementioned blog post |
| 17:01 | <AryehGregor> | Yeah, I saw in the comments. |
| 17:01 | <othermaciej> | that blog post has a giant flamewar in the comments, yay |
| 17:02 | <AryehGregor> | "An essential part of the Wikimedia Foundation's mission is encouraging the development of free-content educational resources that may be created, used, and reused by the entire human community. We believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse." |
| 17:02 | <AryehGregor> | Maybe HTML5 is an "open format" if it's not an "open standard"? |
| 17:02 | AryehGregor | doesn't care, is calling it a standard regardless |
| 17:03 | <othermaciej> | if you want to market your compliance with HTML5, you probably need to do that actively by telling people how to check |
| 17:03 | <othermaciej> | I don't think it's the W3C's job to make it as easy as possible for you to impress people |
| 17:05 | <AryehGregor> | It's not about impressing people, it's about evangelism. It's kind of hard for an organization to advocate web standards if it's perceived as not complying with them. |
| 17:06 | <AryehGregor> | Anyway, regardless of us, it's misleading to validator users to say that the document is non-standard XHTML 1.0 Strict when it's actually valid HTML5. You could also say it's non-standard HTML 3.2, but that would be silly. |
| 17:06 | <othermaciej> | is there a place where I can find information on the standards Wikipedia (and/or MediaWiki) claims to conform to? |
| 17:07 | <AryehGregor> | Nowhere official. Everything I've said here is my own opinion as a volunteer. Historically, MediaWiki has attempted to conform to XHTML 1.0 Transitional, and now I'm trying to get it to conform as HTML5. |
| 17:08 | <AryehGregor> | It also tries to conform to CSS and so on, where practical. |
| 17:09 | <othermaciej> | I guess what I'm saying is, if it's important for Wikipedia to know about your standards compliance, it seems like one obvious first step would be for Wikipedia to document its own standards compliance efforts in a publicly visible way |
| 17:09 | <othermaciej> | but anyway I guess I have said enough on this topic |
| 17:09 | <AryehGregor> | Validators are what people use to judge standards compliance. |
| 17:10 | <Philip`> | Maybe MediaWiki should try to evangelise better ways of judging standards compliance |
| 17:10 | <AryehGregor> | That's the problem. Few people understand anything about the standards, they rely on validators to tell them whether something is conforming. |
| 17:12 | <AryehGregor> | Wikimedia seems to mostly be focusing its evangelism efforts right now on Theora, although by now it's unfortunately turned out to be a lost cause (IMO). |
| 17:13 | <AryehGregor> | Although standards evangelism is far from a primary goal of Wikimedia, anyway. |
| 17:13 | <othermaciej> | I don't think wikipedia is the proper organization to evangelize standards |
| 17:14 | <othermaciej> | I'm thinking of a page that says things like "Wikipedia strives to be compliant to web standards including HTTP 1.1, HTML5 and CSS 2.1. Here are some ways in which we don't always meet that goal. Here is how to check for yourself." etc |
| 17:15 | <othermaciej> | writing is hard though and if the list grows to be more than a shortlist it can spawn excess debate |
| 17:15 | <othermaciej> | I guess some form of SVG should also be in that list |
| 17:16 | <AryehGregor> | That seems superfluous. Isn't just saying "we try to be standards-compliant" enough? It's pretty clear what HTML standard we use (currently XHTML 1.0 Transitional), and there are really no major conflicts between the versions of other standards (CSS, HTTP, etc.). You can just assume the latest. |
| 17:16 | <AryehGregor> | (not that we find it necessary to officially say we try to be standards-compliant, we just do it, where it's reasonable) |
| 17:16 | <AryehGregor> | Does WebKit have an official list of standards that it tries to implement correctly? |
| 17:22 | <othermaciej> | we have tried to make such a list for WebKit but it started getting pretty long and hard to maintain |
| 17:22 | <othermaciej> | http://trac.webkit.org/wiki/SpecSupport |
| 17:22 | <AryehGregor> | Opera and IE have such lists, I think. |
| 17:22 | <othermaciej> | extremely incomplete list |
| 17:22 | <AryehGregor> | It doesn't seem like a worthwhile use of time to me. |
| 17:23 | <othermaciej> | and out of date |
| 17:23 | <othermaciej> | there's probably at least 50 things that could be added to that list |
| 17:24 | <othermaciej> | I think we need to have a more complete and up-to-date list though, if only for our own purposes |
| 17:24 | <AryehGregor> | Well, implementers tend to refer to actual specs a lot more than authors. If anything, authors mostly just get it to validate and leave it at that. |
| 17:25 | <AryehGregor> | Maybe it's more useful to implementers to keep tabs on exactly what specs they need to refer to. |
| 17:25 | <AryehGregor> | It doesn't seem useful to me as an author. |
| 17:26 | <othermaciej> | it's useful for us so that we can keep track of whether patches are part of a standard we approve of, or whether they need closer examination |
| 17:26 | <othermaciej> | also to document the state of things for content authors, because they seem interested in what standards we support |
| 18:16 | <MikeSmith> | [me finally has a short meeting break] |
| 18:18 | <MikeSmith> | AryehGregor: fwiw, I will be working actively on getting a production instance of validator.nu set up in W3C webspace |
| 18:18 | <AryehGregor> | Great. |
| 18:19 | <MikeSmith> | but I will not be working actively on any further changes to the existing markup validator |
| 18:19 | <MikeSmith> | for that your best bet is to talk with Ville Skyttä |
| 18:19 | <AryehGregor> | Sure. Thanks. |
| 18:20 | <MikeSmith> | there is not really any team of people working on the existing validator |
| 18:20 | <MikeSmith> | it is basically just Ville Skyttä |
| 18:20 | MikeSmith | didn't know about http://trac.webkit.org/wiki/SpecSupport |
| 18:21 | <othermaciej> | MikeSmith: it's very out of date so don't use it as a reference |
| 18:22 | <othermaciej> | but maybe it will be one of the next things I decide to fix up |
| 18:22 | <MikeSmith> | othermaciej: I just tweeted it |
| 18:23 | <othermaciej> | great, now I have to fix it |
| 18:23 | <MikeSmith> | It seems worth trying to keep up-to-date |
| 18:23 | <MikeSmith> | othermaciej: I would be willing to help keep it up to date |
| 18:25 | <MikeSmith> | othermaciej: or I also can delete that tweet |
| 18:26 | MikeSmith | deletes it |
| 18:26 | <othermaciej> | it's not actually that big a deal, sorry for making it sound like one |
| 18:27 | othermaciej | is loopy from lack of sleep and from stress over we will ever get to Last Call |
| 18:28 | MikeSmith | has spent quite a bit of time the previous several days discussing progress of HTML5 to Last Call |
| 18:28 | <MikeSmith> | othermaciej: I've been here in Cambridge since the 17th |
| 18:28 | <MikeSmith> | and will be here through the 31st |
| 18:29 | <othermaciej> | neat |
| 18:29 | <othermaciej> | I wonder what Hixie has been up to |
| 18:30 | <othermaciej> | there has not been much bug closing for a while |
| 18:30 | <othermaciej> | though we really need to get more issues closed out too |
| 18:32 | <MikeSmith> | Hixie seems to have had his head down doing especially concentrated work on something for a while now |
| 18:34 | <othermaciej> | seems like a pretty low volume of spec commits this month |
| 19:17 | AryehGregor | notes that Chrome and Gmail both offer to translate his e-mails now, except that Gmail is smart enough not to keep offering after he's gone on to the next e-mail |
| 19:18 | <MikeSmith> | AryehGregor: do you get a lot of e-mail in different languages? |
| 19:18 | <AryehGregor> | Yes, I get localization update e-mails every day from the MediaWiki commit list. |
| 19:19 | <AryehGregor> | Like: http://lists.wikimedia.org/pipermail/mediawiki-cvs/2010-March/085047.html |
| 19:19 | <AryehGregor> | Or: http://lists.wikimedia.org/pipermail/mediawiki-cvs/2010-March/085041.html |
| 19:19 | <AryehGregor> | I don't actually care to read them, obviously. |
| 19:41 | <MikeSmith> | I didn't know Chrome itself actually had a means for offering to translate a page |
| 19:42 | <MikeSmith> | I guess I need to start using it more |
| 19:42 | <AryehGregor> | They just added it to the dev channel. |
| 19:42 | <MikeSmith> | ah, OK |
| 19:43 | AryehGregor | has found the dev channel a bit too unstable for his liking, but is too lazy to switch to beta |
| 19:43 | <MikeSmith> | I try to mix up my browsing across as many major browsers/engines as I can |
| 19:43 | <MikeSmith> | but I find I end up using some a lot more than others |
| 19:45 | <AryehGregor> | I just use Chrome where possible now. At least on Linux, I find it feels much more responsive than Firefox. |
| 19:45 | <AryehGregor> | And I never was an extension junkie, extensions are unreliable and slow. |
| 19:46 | <AryehGregor> | Firefox is second-place for me now. |
| 19:52 | <nessy> | can't live without firebug! |
| 19:53 | <Dashiva> | Does Chrome have live source editing within the browser? |
| 19:54 | <AryehGregor> | It has WebKit's Web Inspector. |
| 19:54 | <AryehGregor> | I've found it works about as well as Firebug. |
| 19:54 | <AryehGregor> | Maybe I missed out on some of Firebug's hard-core features. |
| 19:54 | <AryehGregor> | On the plus side, Web Inspector doesn't break all the time when you upgrade, and you can be sure it's not sucking up resources because everyone has it installed. |
| 19:56 | <AryehGregor> | I think Firebug is better on that than it used to be. I remember a few years ago getting a warning from Gmail along the lines of "You're using Firebug, we suggest you don't because it tends to slow down Gmail horribly." |
| 19:57 | <AryehGregor> | That was before they made some things disabled by default, like network monitoring. |
| 20:04 | <Dashiva> | A minor diversion: http://www.foxtrot.com/comics/2010-03-21-75f89edd.gif |
| 20:18 | <MikeSmith> | nessy: Web Inspector works pretty well and is definitely worth trying |
| 20:19 | <MikeSmith> | AryehGregor: I guess Web Inspector is one of the features that leads me to end up using a particular browser/engine more than others |
| 20:20 | <nessy> | yeah, it's good that most browsers now have something like firebug |
| 20:20 | <nessy> | didn't used to be the case |
| 20:20 | <MikeSmith> | yep |
| 20:20 | <MikeSmith> | Firebug was really a big part of the inspiration for all the others |
| 20:21 | <MikeSmith> | I just wish that all browsers had development/debug tools built-in |
| 20:22 | <MikeSmith> | among other reasons, it just makes upgrading a lot easier |
| 20:22 | <MikeSmith> | if the debugging tools get tested a part of the normal build/release cycle |
| 20:23 | <MikeSmith> | including with the development builds |
| 20:25 | <Philip`> | Which browsers don't have them built-in? |
| 20:26 | <Philip`> | Opera has Dragonfly, IE has its developer tools, Safari/Chrome have Web Inspector |
| 20:26 | <Philip`> | Firefox is the only one that doesn't |
| 20:26 | <Philip`> | and installing Firebug is trivial |
| 20:29 | <Dashiva> | I'm looking for the equivalent of Opera's view source -> edit -> apply changes |
| 20:30 | <Philip`> | View source, copy, http://software.hixie.ch/utilities/js/live-dom-viewer/, paste |
| 20:32 | <Dashiva> | That doesn't work when doing script + stylesheet interaction :) |
| 20:33 | <Dashiva> | E.g. just now there was this script that failed in Opera, so I added a line to show the error condition and got the answer right away |
| 21:07 | <Philip`> | Hmph, I beat annevk by two minutes but used the wrong email address so my message got held up :-( |
| 21:08 | <annevk> | not here |
| 21:09 | <annevk> | teaches me to write email after 10PM |
| 21:31 | <jgraham> | FWIW I think the block-inside-<a> thing is probably a bad idea |
| 21:32 | <jgraham> | Because it doesn't work in a lot of cases to trying to use it has inconsistent results |
| 21:32 | <jgraham> | OTOH I don't feel like it is worth some huge war |
| 23:11 | <Dashiva> | View source and find to do page validation... right |
| 23:16 | <TabAtkins> | I don't want to violate my policy of "ignore Shelley", but yeah, that one *almost* got a reply out of me. |
| 23:17 | <Dashiva> | I have a better policy: Let's just write conforming documents to begin with |
| 23:30 | <Philip`> | Dashiva: HTML WG experts can often write mostly-conforming HTML by hand, so it seems best to design the spec around the expectation that everyone is like that |
