00:33:53 mjs has joined #html-wg
00:48:47 julian has joined #html-wg
01:08:51 changes: hixie: Editorial fixes: a paragraph that shouldn't be class=impl; a missing xref. (whatwg r4001) <11http://lists.w3.org/Archives/Public/public-html-diffs/2009Sep/0253.html>
01:36:41 cheeaun has joined #html-wg
01:36:47 cheeaun has left #html-wg
03:37:52 Dashiva has joined #html-wg
03:38:23 cardona507 has joined #html-wg
03:55:44 mjs has joined #html-wg
05:32:28 DanC_lap has joined #html-wg
05:37:48 MikeSmith has joined #html-wg
05:39:01 Rodi has joined #html-wg
05:45:01 Rodi has left #html-wg
05:59:11 MarcoAchury has joined #html-wg
06:48:31 gavin has joined #html-wg
07:11:39 issue: suggested replacement for head/@profile does not provide for disambiguation
07:11:40 Created ISSUE-82 - Suggested replacement for head/@profile does not provide for disambiguation ; please complete additional details at http://www.w3.org/html/wg/tracker/issues/82/edit .
07:12:09 issue-82: escalated from http://www.w3.org/Bugs/Public/show_bug.cgi?id=7522
07:12:09 ISSUE-82 Suggested replacement for head/@profile does not provide for disambiguation notes added
07:12:10 117522: contributor@whatwg.org, P3, RESOLVED FIXED, 13 should also be phrasing and flow content, like .
07:12:53 dammit
07:13:08 issue-82: escalated from http://www.w3.org/Bugs/Public/show_bug.cgi?id=7512 (not 7522...)
07:13:08 ISSUE-82 Suggested replacement for head/@profile does not provide for disambiguation notes added
07:13:08 117512: julian.reschke@gmx.de, P2, NEW, 13suggested "replacement" for head/@profile does not work
07:31:01 sbublava has joined #html-wg
08:07:19 mjs has joined #html-wg
08:38:15 ROBOd has joined #html-wg
09:17:37 ChrisWilson has joined #html-wg
09:31:19 Lachy has joined #html-wg
09:40:56 bugmail: [Bug 7725] New: It should be made more clear that only the "disk representation" is changed, not the "memory representation". I.e. images are not suddenly reloaded etc. <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0820.html>
09:57:14 tH has joined #html-wg
10:08:00 Henri, is it intentional that validator.nu issues an error for the legacy doctype?
10:11:04 bugmail: [Bug 7726] New: legacy doctype syntax allows <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0821.html>
10:17:45 julian: seems like a clear bug to me
10:18:16 mjs, filing a bug...
10:18:17 I don't believe hsivonen has stated his intent to violate the spec on this, it is probably just something that hasn't yet been updated
10:18:40 the message I get implies that it's intentional
10:20:03 maybe I misunderstood the spec
10:20:08 http://bugzilla.validator.nu/show_bug.cgi?id=657
10:20:09 Title: Bug 657 legacy doctype causes validation error (at bugzilla.validator.nu)
10:20:31 "The DOCTYPE legacy string should not be used unless the document is generated from a system that cannot output the shorter string."
10:21:05 As the validator doesn't know how the HTML code was generated, an error seems to be incorrect to me.
10:21:47 and in any case that is a SHOULD NOT, not a MUST NOT
10:22:07 I guess it should be a warning not an error?
10:22:53 I can see why some might want to issue a warning.
10:23:11 Fro my point of view this is one of the many cases of overspecification.
10:23:34 The doctype is totally harmless, so IMHO there shouldn't even be a SHOULD NOT.
10:23:47 Just explain why it's there. End of story.
10:24:22 In particular it's in violation of the RFC2119 advice on when to use the keywords
10:24:37 didn't HTML5 change to require " Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not...
10:24:45 ...required for interoperability."
10:25:57 the retransmission thing seems applicable, no?
10:26:19 I think almost all authoring requirements are in violation of RFC2119 advice on when to use the keywords
10:26:44 Retransmissions? Why would there be any?
10:26:45 so the problem is that HTML5 claims it's using RFC2119 terminology when it's not
10:27:10 (which could perhaps be fixed by not claiming to be using RFC2119 terminology, and by defining what it does mean by those terms)
10:27:25 Philip, that's likely true. Most specs over-use them, as the authors do not understand that they can write normative text without them.
10:29:09 A nice counter-example is RFC3986.
10:29:45 julian: my preference would be to make any doctype that triggers standards mode conforming
10:30:05 julian: but I don't feel very strongly about that
10:30:19 mjs, +1
10:30:42 Even HTML4 doctypes?
10:31:06 ones that trigger standards mode, yes
10:31:07 actually, yeah, that'd be my preference too
10:31:31 if the document is in standards mode, than using an old-style doctype causes no interop issue
10:31:40 That would be confusing when you put your HTML4-doctyped conforming HTML5 document through the W3C validator and it gets validated as HTML4 instead
10:32:11 Maybe even those - assume a perfectly valid HTML4 document -- why should it be non-conformant in HTML5 if the only required change is the doctype?
10:32:41 Philip, I wouldn't find that confusing.
10:32:42 Non-interoperability with common validators seems like a problem
10:32:45 Philip, well, the validator should always validate according to the latest HTML standard
10:32:50 and I believe the short form is very well marketed and indeed sells itself, so the value of telling authors they could have used the shorter thing is low
10:33:21 I think the validator should validate text/html as HTML5 by default at some point, and only validate as a different version if you specifically ask, instead of switching on the doctype
10:33:37 I don't see why the validator should support versioning if nobody else does
10:33:54 but I suppose that would be a plausible reason to make formerly used doctypes invalid, if the w3c validator won't do that
10:33:59 anne: I can't imagine ever convincing W3C people that the validator should validate HTML4 documents with HTML4 doctypes as if they were HTML5, because it would cause a huge outcry when loads of people's valid HTML4 documents suddenly start getting called invalid HTML5
10:35:17 Philip, if the W3C validator doesn't want to comply it's just non-compliant
10:36:18 Indeed, so that's a practical interoperability problem, and RFC2119 suggests the spec should use 'MUST' to prevent people encountering interoperability problems
10:37:35 The spec can simply say that all these doc types are conforming, but if you want to force a validator to validate as HTML5 you better use one of the new ones.
10:38:01 And, btw, interop with validators is probably not what the authors of RCF2119 were considering .-)
10:38:08 gavin has joined #html-wg
10:38:33 I've lost my enthusiasm for making all doctypes that trigger standards mode conforming
10:39:03 if we don't count interop between content producers (human and automated) and validators, then RFC2119 would suggest we should delete the notion of document conformance
10:39:34 it has its share of advocates
10:39:59 I used to think that way, but hsivonen convinced me that interop between content producers and validators is important
10:40:55 HTML5 does claim to follow it however
10:41:07 jgraham: That's why I kind of vaguely think it might be nice if someone wrote something that was similar to RFC2119 but defined the keywords in a way that matches how they're used in practice by HTML5-like spec
10:41:11 bugmail: [Bug 7727] New: legacy doc type does not need to be discouraged by "SHOULD NOT" <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0822.html>
10:41:46 I tend to agree. But this is so far out into the spec purity weeds that it's scary
10:42:05 but I think it's fair to say that you should be able to get at least some core shared error checking functionality from a validator without having to switch validators every time you switch CMSes
10:42:24 It would be easier if we got rid of conformance requirements and specs entirely, and just produced test suites
10:42:47 since then we wouldn't have to worry about the semantics of the words used
10:42:54 Philip: It would be hard for people writing the testsuites to agree on what they should test...
10:42:56 the problem is that even though some central definition of error is needed to make such an ecosystem work, it's somewhat arbitrary what is defined to be an error
10:43:14 (also, how would you produce a test suite for content)
10:43:29 jgraham: You produce a test suite for validators
10:44:07 a validator is the dual of a test suite
10:45:41 Count the number of web pages with "the W3C validator says my page is okay!" badges, vs the number of pages with "I read the entire HTML4 spec and checked that my page follows all the document conformance requirements!" badges
10:46:12 and you will clearly see that a test suite for validators will have much more effect on authors than a list of document conformance requirements
10:47:01 depends on whether you expect validators to code to test suites more than to conformance requirements
10:47:35 I'm afraid valid arguments aren't allowed here
10:48:48 It depends on whether you believe in non-machine-checkable conformance requirements
10:49:18 julian: I guess I've only allowed about:legacy-compat in the HTML5 doctype expectation mode
10:49:38 julian: but I've forgotten to make it have HTML5ness in the auto expectation mode
10:50:34 whether the space is allowed between SYSTEM and " is a different thing
10:51:24 julian: should be easy to fix once I've flushed Gecko-oriented changes from my parser sandbox
10:51:35 mjs: (I suppose the problem with coding to test suites is overfitting, so I guess you really need conformance requirements to tell people what is right and test suites to tell them when they're wrong)
10:51:54 (so I suppose we can't simplify the world by getting rid of specs :-( )
10:52:50 I was going to say that a test suite can't generally test unbounded combinations of things, not sure if that is what you mean by overfitting
10:53:33 (i.e. you could always be evil and claim the concatenation of two items in the test suite can behave in any random way, assuming that's not also in the test suite, and it's not possible for all concatenations to be in the test suite)
10:53:42 but conformance requirements can express a universal quantifier
10:56:49 I mean an implementor could write 'if (input == "...the first test case...") return "...the relevant output..."; else ...'
10:57:35 so it's describing artifacts of the test suite rather than describing the underlying model
10:58:58 (like with machine learnings algorithms that can accurately fit the training data but don't generalise to new data)
10:59:17 (which Wikipedia agrees is called overfitting, I think)
11:04:33 Philip: So you don't plan to write a web browser using random code generation and a genetic algorithm, with "goodness of fit" determined by test results passed?
11:08:24 You know, I was actually thinking of that
11:08:30 at least for the parsing algorithm
11:09:09 although maybe it would be illegally cruel to subject a neural network to the details of HTML parsing
11:16:37 mjs: I think it also makes sense to do what the spec does now: making those standards-mode doctypes that were previously promoted by the W3C conforming
11:17:30 mjs: I don't see why we'd want to make home-grown custom DTD stuff that happens to trigger the standards mode conforming
11:18:23 V.nu already implements this part of the spec when the parser is in the HTML5 mode as opposed to the autodetect mode
11:20:01 hsivonen: does it actually do that?
11:20:56 I think HTML5 only makes and the legacy doctype conforming
11:21:04 mjs: nope
11:21:09 unless there are document conformance requirements hidden in the parsing section
11:21:11 unless Hixie changed the spec again
11:21:30 those are the only two doctypes mentioned in the "HTML syntax" section
11:21:39 mjs: try on html5.validator.nu
11:21:51 I get: Warning: Obsolete doctype. Expected .
11:21:56 but no error
11:21:58 per spec
11:22:04 Philip: Why?
11:22:19 mjs: obsolete but conforming FTW!
11:22:19 jgraham: Why what?
11:22:49 but maybe my understanding of "obsolete" is wrong
11:23:08 Philip: Why are you considering making a genetically-evolved HTML parser?
11:23:10 it made more sense when they were called downplayed errors
11:23:30 I see, there's a list of "obsolete permitted doctypes"
11:23:31 anne: in "obsolete but conforming" "obsolete" has its normal English meaning--not the spec terminology meaning
11:23:35 hidden in the parsing section
11:23:37 henri, thanks (I was away for lunch)
11:23:57 Maybe we could call such things deprecated :)
11:24:00 jgraham: For the same reason I consider all kinds of stupid things that I have no intention of ever actually doing (and probably no ability to ever do, either)
11:24:29 and that would never work
11:24:30 HTML5 actually says its conforming for validators to check documents with those doctypes as HTML4
11:24:45 mjs: that's what v.nu does in the autodetect mode
11:24:50 Philip: There are a multiplicity of different reasons that you give, at least, for doing the tings you do
11:25:03 I wasn't aware of a single underlying reason
11:25:21 s/same reason/same reasons/
11:25:50 Philip: All of them. I guess some reasons that you have done other things don't apply in this case
11:25:52 Mostly it's just because it's easier to consider doing stupid things than to actually do useful things
11:26:09 s/./?/
11:27:11 jgraham: What do you mean by "??????????????????????????????????????????????????????????????????????????????????????????"?
11:27:53 Philip: INSUFFICIENT_MAGIC_ERROR
11:28:00 Philip: you need to parser the regexp in the quirks mode
11:28:05 *parse
11:41:27 planet: Opacity: Fancy a design tool with “Save as Canvas”? <11http://feedproxy.google.com/~r/ajaxian/~3/Gz_B62SO-Y4/opacity-fancy-a-design-tool-with-save-as-canvas>
11:45:41 pimpbot: apparently is the new PostScript
11:45:42 hsivonen: Huh?
11:46:05 SVG is to what PDF is to PostScript
11:46:07 roughly
11:47:08 "Burst engine, which can take SVG animations and convert them to JavaScript objects that are rendered inside of a tag."
11:47:12 that seems just wrong
11:47:26 Anne, see http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0834.html
11:47:27 Title: Re: Fwd: New Version Notification for draft-murata-kohn-lilley-xml-03 from Julian Reschke on 2009-09-24 (ietf-http-wg@w3.org from July to September 2009) (at lists.w3.org)
11:47:34 "which also brings advice on the use of the charset parameter into line with current practice. In brief, the charset parameter should only be added if it agrees with the xml encoding declaration. In the absence of an explicit charset parameter, the encoding specified by the xml encoding declaration is used. (This is a change from RFC 3023, which required enforcing us-ascii in that case)."
11:47:53 julian, did you read the draft?
11:48:00 If only Javascript had been based on Forth rather than Self, postscript could be the new postscript
11:48:13 Anne, not yet - are you saying what they claim is not true?
11:48:42 julian, not for text/xml per the draft
11:48:56 julian, maybe the previous draft said something broken for non-text/xml too?
11:49:19 saving an animation as code to draw on a canvas actually does not seem like a bad idea
11:49:54 (compare with the alleged syntax-based construction of RDFa)
11:50:35 mjs: shouldn't the author let the browser's SVG subsystem run the animation with UA-controlled clock and zooming?
11:50:55 s/zooming/size of backing buffer bitmap/
11:51:16 Anne, so they changed it only for application/xml
11:51:18 depends on the memory use, code size, and performance characteristics of the result
11:51:53 julian, reading RFC 3023 there was no weird default for application/xml
11:52:13 julian, so I've no idea what that paragraph is alluding too
11:52:24 these days, I'm running most Web pages at home with a > 1.0 zoom factor, so I'm rather annoyed at canvas-based "vector graphics" that are just as pixelated as bitmaps
11:52:31 so I want to see more SVG
11:52:47 or UA-sized canvas backing buffers
11:52:48 Anne, I agree.
11:53:09 It's also not mentioned in the "Changes" appendix.
11:53:15 Mail sent.
11:53:16 ah
11:53:36 WebKit is able to run at a > 1.0 zoom factor and scales the canvas buffer appropriately
11:53:42 julian, almost nothing changed: http://tools.ietf.org/rfcdiff?url2=draft-murata-kohn-lilley-xml-03.txt
11:53:43 but not all canvas code is prepared for the consequences
11:53:44 Title: Diff: draft-murata-kohn-lilley-xml-02.txt - draft-murata-kohn-lilley-xml-03.txt (at tools.ietf.org)
11:53:51 julian, maybe they uploaded the wrong draft...
11:54:04 (anything that does pixel-level munging is almost certainly not coded resolution-independent)
11:54:22 Anne, we'll find out.
11:58:06 mjs: I run OS X at scale factor 1.0 because people haven't done their QA correctly at other factors
11:58:27 mjs: then I run Firefox. it remembers my zoom factor per-site
11:58:40 mjs: which is more important than the hi-res backing buffer from Safari
11:59:18 I'm just saying, the fact that your use case doesn't work as you like it is not a failure of canvas as a design
12:00:55 mjs: it's a failure in the rollout of the design
12:02:43 in any case, if I were deploying animated graphics to the Web, I would care more about size on the wire and memory use than people who love zooming all their web sites
12:03:00 there may well be cases where animated GIF wins this comparison
12:04:36 It's not about loving to zoom
12:04:58 it's about having an unusual screen size (37") and an unusual viewing distance (3 m)
12:05:23 that is indeed unusual
12:05:53 it's what happens when you use one these things legacy-oriented marketers call "TVs"
12:41:43 planet: Dive Into HTML 5, Intro Articles, and IE 6 Cheatsheet <11http://feedproxy.google.com/~r/ajaxian/~3/mrrrM3GR65A/dive-into-html-5-intro-articles-and-ie-6-cheatsheet>
12:55:18 Lachy has joined #html-wg
13:03:13 sryo has joined #html-wg
13:11:15 DanC_lap has joined #html-wg
13:26:38 gavin has joined #html-wg
13:50:00 aroben has joined #html-wg
13:51:48 aroben has joined #html-wg
14:12:18 laplink has joined #html-wg
14:17:22 I remember mail about an implementation on the microdata stuff... but I can't find it in the archives... too much recall and too little precision when searching for "microdata implementation"
14:17:32 anybody have clues/pointers?
14:17:47 DanC_lap: http://philip.html5.org/demos/microdata/demo.html ?
14:18:00 Also http://james.html5.org/microdata/
14:18:01 Title: HTML 5 Microdata Extractor (at james.html5.org)
14:18:19 pimpbot, why no title for mine? :-(
14:18:19 Philip: Huh?
14:18:38 thanks!
14:18:49 DanC_lap: Mine, at least is out of date wrt the current spec
14:19:07 Oh, right, because I don't have a element except in a textarea that gets scriptedly inserted into the document
14:19:09 <jgraham> But I see no point in updating it until Hixie has finished his usability study
14:19:13 <Philip> Mine is out of date too
14:19:22 <Philip> (I think)
14:21:19 <Philip> I see no point in updating mine because RDFa is going to conquer the world
14:24:31 <jgraham> I for one welcome our new RDFa overlords
14:28:51 <Philip> I wonder if the overlords will force me to memorise which attributes take URIs, which take CURIEs, and which take Safe CURIEs
14:33:45 <hsivonen> jgraham: maybe the other technologies don't like to be associated with dangerous characteristics of matter
14:33:49 <hsivonen> like radiation
14:34:23 <Philip> I want a web technology that's RAD
14:34:26 <hsivonen> am I confusing curies and sieverts?
14:34:37 <jgraham> No Curies are units of radiation
14:35:55 <jgraham> I plan to invent TESLA and GAUSS. My aim will be to make them as similar as possible whilst having vastly different meanings
14:39:05 <Philip> Someone on a blog noted the irony of a technology for abbreviating URIs having a name that is not actually a proper abbreviation of anything
14:41:07 <hsivonen> Philip: it's also longer than "URI"
14:41:53 <Philip> Maybe they should have been called CUs
14:42:07 <Philip> or CIs, depending on your preferred spelling of 'address'
14:42:15 <Philip> Actually, just call them Cs and then there's no problem
14:42:16 <pimpbot> planet: Chromie <11http://intertwingly.net/blog/2009/09/22/Chromie>
14:43:00 <jdandrea> jdandrea has joined #html-wg
14:43:27 <jdandrea> jdandrea has joined #html-wg
15:04:49 <Shunsuke> Shunsuke has joined #html-wg
15:07:43 <jdandrea> jdandrea has joined #html-wg
15:21:10 <tlr> tlr has joined #html-wg
15:42:31 <pimpbot> planet: Web platform + Mobile future = A new adventure; Joining Palm with Ben <11http://almaer.com/blog/joining-palm-with-ben>
15:46:33 <Dashiva> Dashiva has joined #html-wg
15:47:57 <gsnedders> gsnedders has joined #html-wg
15:48:07 <sbublava> sbublava has joined #html-wg
15:50:09 <Lachy> Lachy has joined #html-wg
16:07:25 <Zeros> Zeros has joined #html-wg
17:01:16 <sbublava> sbublava has joined #html-wg
17:10:10 <hober> hober has joined #html-wg
17:24:52 <DanC_lap> DanC_lap has joined #html-wg
17:40:58 <drunknbass_work> drunknbass_work has joined #html-wg
17:43:05 <pimpbot> planet: theora 1.1 is released – what you should know <11http://hacks.mozilla.org/2009/09/theora-1-1-released/>
17:50:27 <DanC_> DanC_ has joined #html-wg
18:31:25 <DanC_> DanC_ has joined #html-wg
18:43:18 <pimpbot> changes: hixie: Make a number of clarifications for authors. (forms-related stuff) (whatwg r4002) <11http://lists.w3.org/Archives/Public/public-html-diffs/2009Sep/0254.html>
19:01:55 <DanC_> DanC_ has joined #html-wg
19:13:24 <pimpbot> changes: hixie: Use INVALID_STATE_ERR rather than INVALID_ACCESS_ERR in a number of cases. (whatwg r4003) <11http://lists.w3.org/Archives/Public/public-html-diffs/2009Sep/0255.html>
19:31:14 <J_Voracek> J_Voracek has joined #html-wg
19:31:55 <DanC_> DanC_ has joined #html-wg
20:46:47 <heycam> heycam has joined #html-wg
21:00:21 <Lachy> Lachy has joined #html-wg
21:13:51 <pimpbot> bugmail: [Bug 7724] I would like to know: what is to become of the A element’s NAME attribute? I validated a HTML5 website that I am working this Wednesday (2009-09-23) which contained an A element with a NAME attribute: the W3C Markup Validator did not mind one bit. Howe <11http://lists.w3.org/Archives/Public/public-html-bugzilla/2009Sep/0823.html>
21:17:58 <mjs> mjs has joined #html-wg
21:20:52 <J_Voracek> J_Voracek has joined #html-wg
21:26:35 <tlr> tlr has joined #html-wg
21:59:32 <MikeSmith> MikeSmith has joined #html-wg
22:03:01 <shepazu> shepazu has joined #html-wg
23:01:11 <Zeros> Zeros has joined #html-wg
23:21:23 <gavin> gavin has joined #html-wg
23:59:34 <drunknbass_work> drunknbass_work has joined #html-wg