| 00:15 | <Hixie> | othermaciej_: renaming them to "studying existing practices" and "studying existing implementations" is nice, gives it good symmetry and sidesteps the whole kneejerk reaction, i like it. |
| 00:16 | <othermaciej> | Hixie: yeah, that's sort of the idea |
| 00:16 | <othermaciej> | idiomatic, punchy names are fun to say, but they seem to promote controversy |
| 00:16 | <Hixie> | yeah |
| 00:40 | <MikeSmith> | I think the idiomatic names are more than just fun to say; they have the advantage of already being familiar to people and capture the ideas more succinctly, though with the downside of being less precise |
| 00:43 | <MikeSmith> | the alternative of being more precise risks watering down some ideas to the point where they have a lot less value in quickly and clearly making the high-level design goals more clear to outside parties who have not been involved in the discussions |
| 00:45 | <MikeSmith> | the general slide toward meaninglessness that trying to get general consensus over language issues always brings |
| 00:47 | <MikeSmith> | "The faultfinder will find fault even in paradise.", to quote a little Thoreau |
| 00:48 | <othermaciej_> | idiomatic names are great when there is a consistent shared understanding of them |
| 00:48 | <othermaciej_> | but some of the current ones (the Wheel and Cowpaths ones in particular) are widely misunderstood, to the point of seriously damaging their helpfulness |
| 00:51 | <Lachy> | I don't want cowpaths renamed, but if it must, then we need to pick something good |
| 00:51 | <MikeSmith> | othermaciej - OK, then I can see it making sense to changing them |
| 00:52 | <MikeSmith> | Though I guess I would wonder just how widely they are misunderstood relative to any other such idioms |
| 00:52 | <MikeSmith> | all idioms risk being misunderstood |
| 00:54 | <MikeSmith> | I guess we need to consider if we are more interested in making the document easily and quickly understand to clueful people than we are to trying to prevent it from being misunderstood by less clueful people |
| 01:05 | <jacobolus> | Hixie: line 24774 of html5 spec, has a <?p> instead of </p> |
| 01:05 | <Hixie> | thanks |
| 01:05 | <Hixie> | it'll get fixed in due course hopefully |
| 01:06 | <jacobolus> | :) |
| 01:06 | <Hixie> | right now i'm in the middle of a complicated edit |
| 01:06 | <jacobolus> | pretty minor detail |
| 01:06 | <jacobolus> | so no worries |
| 01:06 | <jacobolus> | thought you'd like to know though :) |
| 01:06 | <Hixie> | yup, thanks :-) |
| 04:54 | <Hixie> | so what makes one an accessibility expert anyway |
| 04:55 | <Hixie> | since there seems to be at least as little agreement between the self-styled accessibility experts as there is between members of any other self-styled community |
| 04:55 | <Hixie> | e.g. software engineers |
| 04:57 | <othermaciej> | one may as well ask what makes one an expert on any topic |
| 04:57 | <Hixie> | well in some cases, a degree |
| 05:02 | <othermaciej> | that doesn't seem applicable to anything software-related however |
| 05:03 | <Hixie> | yeah |
| 06:01 | <jacobolus> | Hixie: are there some examples of accessibility experts whose resumes can be examined? |
| 06:01 | <jacobolus> | Hixie: maybe there's a pattern |
| 06:06 | <Hixie> | jacobolus: not that i know of |
| 06:06 | <jacobolus> | you don't know of accessibility experts? or patterns? |
| 06:08 | <jacobolus> | Hixie: I see a link in a google search for a pdf: “Become an Accessibility Expert in 50 min” |
| 06:08 | <jacobolus> | so maybe you too can be one |
| 06:09 | <jacobolus> | whoa: " * Stuff to impress your Client & Boss with. * Surprise, it might be you! Who are covered in accessibility issues. * Wow, That’s allot of work." |
| 06:15 | <Hixie> | uri? |
| 06:15 | <jacobolus> | second link: http://www.google.com/search?client=camino&hl=en&q=accessibility%20expert |
| 06:15 | <jacobolus> | http://www.cfconf.org/cfun-04/talks/HAMMAN_BecomeanAccessibilityExpertin50min.ppt |
| 06:16 | <jacobolus> | that's not going to be much practical use, I'm afraid |
| 06:19 | <jacobolus> | it has some good clipart in the corner though |
| 06:21 | <Lachy> | it's difficult to judge who is an expert. I'm sure there are a lot of people who either claim to be, or have been called by others, an accessibility expert, but whom are merely advocates |
| 06:22 | <Lachy> | but those search results include include people like Joe Clark and Gez Lemon, which could be considered a fair assessment of them. |
| 06:43 | <Lachy> | I see Joshue accepted Hixie's invitation to the F2F http://html4all.org/pipermail/list_html4all.org/2007-September/000294.html |
| 07:45 | <Hixie> | heh, someone proposed a way to change http to allow for the content-sniffing behaviour in html5 |
| 07:46 | <Hixie> | but unintentionally they actually proposed making it far wider-reaching than the html5 spec allows |
| 07:47 | <othermaciej> | oh? |
| 07:56 | <Hixie> | othermaciej: on www-tag |
| 08:04 | <othermaciej> | I'm glad the Transatmospheric Architecture Group is on the job |
| 08:06 | <marcosc> | ehehe |
| 08:06 | <hsivonen> | I think asking servers to return 406 more often is not going to help not to Break The Web |
| 08:08 | <hsivonen> | in retrospect, Content-Type seems like a mistake compared to making sure all Web formats had a magic number |
| 08:10 | <hsivonen> | fwiw, implementing the suggestion would wreak havoc with all the PHP scripts out there that serve images from a database and are hosted on Apache 1.3 |
| 08:12 | <othermaciej> | magic numbers don't work well for text formats |
| 08:13 | <hsivonen> | #! works pretty well |
| 08:14 | <hsivonen> | a mandatory <?xml could work, too |
| 08:14 | <hsivonen> | and the UTF-8 BOM is pretty cool |
| 08:17 | <othermaciej> | I guess it depends on whether sending otherwise functional markup to be processed as plain text is considered useful |
| 08:19 | <othermaciej> | these TAG minutes have many interesting moments |
| 08:19 | <othermaciej> | http://lists.w3.org/Archives/Public/www-tag/2007Sep/0071.html |
| 08:25 | <Hixie> | magic numbers for text formats work fine |
| 08:25 | <Hixie> | but anyway, bed time |
| 08:25 | <Hixie> | (i agree that magic numbers would have been the better way forward, in retrospect) |
| 08:26 | <othermaciej> | metadata works better when it's directly attached |
| 08:29 | <othermaciej> | so is it at all common for GIFs to be sent with an image/jpeg content type or the like? |
| 09:17 | <hsivonen> | Lachy: btw, regarding <m> and offset in the Web service formats: I think I could improve the usability of Validator.nu if I highlighted ranges of the source instead of individual points |
| 09:17 | <hsivonen> | Lachy: in which case I'd use heuristics for guessing the start of the range |
| 09:18 | <hsivonen> | (basically, the previous errorless SAX event location would set the start point of the range) |
| 09:20 | <hsivonen> | one problem is that in practice, there are two layers of errors: 1) exact errors from the tokenizer and below and 2) inexact errors locations from above the tokenizer |
| 09:22 | <Lachy> | hsivonen, ok |
| 09:23 | <Lachy> | hsivonen, did you see the comment you got on the blog? |
| 09:23 | <hsivonen> | not yet |
| 09:23 | hsivonen | looks |
| 09:23 | <Lachy> | (it's from me, nothing too exciting) |
| 09:27 | <hsivonen> | replied |
| 09:28 | hsivonen | notes that markp has posted |
| 09:29 | <Lachy> | yeah, mark's post explains the longdesc issue really well |
| 09:31 | <Lachy> | I think I have another idea for how to represent the parse tree in XML, without simply dumping the whole document with a modified namespace |
| 09:32 | <Lachy> | and also an alternative format for JSON |
| 09:32 | <Lachy> | I'll make up a few examples |
| 09:52 | <Lachy> | hsivonen, this is the parse tree in JSON. It gives a simple DOM like interface for authors to traverse. http://tinyurl.com/yowlqm |
| 09:59 | <othermaciej> | hello Lachy |
| 09:59 | <Lachy> | hello othermaciej |
| 10:01 | <hsivonen> | Lachy: a very interesting idea! |
| 10:01 | <hsivonen> | zcorpan: what's your take on Lachy's format vs. SDF? |
| 10:02 | <hsivonen> | Lachy: Thank you! |
| 10:02 | <Lachy> | hsivonen, a slight variation to that idea would be to give it a SAX like interface |
| 10:02 | Lachy | is wondering why othermaciej pinged him |
| 10:03 | <hsivonen> | Lachy: I'm most likely going to use SAX Tree as the internal parse tree representation |
| 10:04 | <zcorpan> | hsivonen: lachy's format seems easier to parse but harder to read/write for humans |
| 10:04 | <othermaciej> | Lachy: I was just saying hi to be friendly |
| 10:04 | <Lachy> | oh, ok. |
| 10:06 | <Lachy> | hsivonen, s/SAX/XOM/ in my last message |
| 10:07 | zcorpan | finds http://jsonml.org/ |
| 10:08 | <zcorpan> | that seems to be designed to be able to express legal trees only |
| 10:08 | <Lachy> | zcorpan, where can I find a simple example to see how it works? |
| 10:09 | <zcorpan> | Lachy: on that page, "Colorful Table Example" |
| 10:09 | <Lachy> | ok, found it |
| 10:10 | <hsivonen> | zcorpan: does it do namespaces? |
| 10:11 | <zcorpan> | hsivonen: doesn't seem like it |
| 10:12 | <Lachy> | oh I see, it represents each element as an array: ["nodeName", { ... attributes ...}, childNode, childNode, ...] |
| 10:12 | <Lachy> | hsivonen, it would probably do namespaces by serialising the xmlns and xmlns:foo attributes into the attributes object |
| 10:14 | <hsivonen> | Lachy: yeah. eww. |
| 10:15 | <hsivonen> | Lachy: though the nature of namespaces is that they are incredibly wasteful to serialize without a compression mechanism like prior declarations |
| 10:15 | <Lachy> | it doesn't seem to handle comment nodes well either and has no support for PIs |
| 10:17 | <Lachy> | zcorpan, does SDF have to serialise the namespace for every non-XHTML element, or does it do inheritance? |
| 10:17 | <zcorpan> | Lachy: the former |
| 10:18 | <zcorpan> | it also doesn't know about the "xml" prefix, e.g. |
| 10:18 | <Lachy> | hsivonen, it really depends what the pupose of a parse tree is, does it really need to have all the namespace info for every node? |
| 10:21 | <hsivonen> | Lachy: somehow, I was assuming that it had to encode everything |
| 10:21 | <Lachy> | I wish the w3 validator didn't remove its parse tree option |
| 10:22 | <zcorpan> | Lachy: indeed, it was one of the actual useful features |
| 10:23 | <Lachy> | the parse tree should, IMHO, just represent how the markup was parsed, not a complete representation of the tree built by the tree builder. |
| 10:23 | <hsivonen> | Unicode normalization is an interesting issue for tools like Validator.nu |
| 10:23 | <hsivonen> | Validator.nu whines if the input isn't in NFC |
| 10:23 | <hsivonen> | so to keep it self-validating, I cannot show the original code points for non-NFC source |
| 10:24 | <hsivonen> | but then, non-b0rked Unicode renderers shouldn't suffer if I normalize |
| 10:25 | <Lachy> | I don't really understand normalisation |
| 10:25 | <hsivonen> | philosophical questions about what the "source" is in the context of a NFC character presentation when the source really consists of bytes |
| 10:27 | <hsivonen> | implementing showing source pedantically correctly in an interesting demo on how non-simple "just normalize to NFC" is |
| 10:27 | <hsivonen> | as the source positions need to stay anchored before and after normalization |
| 10:30 | <hsivonen> | I think that eventually I'm going to sacrifice some perf in order to get some sane separation of concern in the validator.nu internals |
| 10:37 | <Lachy_> | hsivonen, this was my idea for representing the parse tree in XML http://tinyurl.com/24nanw |
| 10:37 | <hsivonen> | Lachy_: thanks. It is verbose, but probably better than my namespace salting idea |
| 10:39 | <Lachy_> | yeah, and it should be able to represent any document at all, whether or not the source was well formed. |
| 10:40 | <zcorpan> | hsivonen: <form name="foo"> is flagged as invalid for html4 documents in validator.nu |
| 10:40 | <Lachy_> | name isn't allowed on <form>, IIRC |
| 10:40 | <zcorpan> | Lachy_: it is in html4 |
| 10:41 | <hsivonen> | zcorpan: do you have a test case with a URI? |
| 10:41 | <zcorpan> | xhtml 1.0 prose says that it is deprecated but it's not present in the xhtml 1.0 dtd |
| 10:41 | <zcorpan> | http://validator.nu/?doc=http%3A%2F%2Fwww.americanhomeinspectordirectory.com%2Findextest.php |
| 10:41 | <hsivonen> | zcorpan: well, that explains it |
| 10:42 | <zcorpan> | yeah. seems to be a mistake in the xhtml 1.0 spec |
| 10:42 | <Lachy_> | it's just one of those many undocumented changes between XHTML1 and HTML4 |
| 10:43 | <Lachy_> | hmm. I wonder why so many comments are being flagged for moderation in the blog. |
| 10:44 | <hsivonen> | at least Relaxed has the same bug |
| 10:44 | <zcorpan> | "HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map." ... "Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML." |
| 10:44 | <zcorpan> | -- http://www.w3.org/TR/xhtml1/#h-4.10 |
| 10:44 | <hsivonen> | zcorpan: thanks. for now, I think I'm going to note this in documentation instead of forking the XHTML 1.0 / HTML 4.01 schema |
| 10:46 | <zcorpan> | and the dtd: http://www.w3.org/TR/xhtml1/dtds.html#dtdentry_xhtml1-strict.dtd_form |
| 10:46 | <zcorpan> | hsivonen: ok |
| 10:47 | <hsivonen> | zcorpan: fixed in documentation |
| 10:49 | <hsivonen> | zcorpan: thanks. (at least I now have a note about the bug in case I overhaul HTML 4.01 support some day) |
| 10:50 | <zcorpan> | hsivonen: np |
| 10:52 | <hsivonen> | I want a streaming Unicode normalizer... |
| 10:55 | <Lachy> | it looks like Rob misunderstands when the spec says alt can be omitted. http://blog.whatwg.org/the-longdesc-lottery#comment-8929 |
| 10:56 | <Lachy> | his example is when the image is illustrative of the surrounding text, but the spec is clear that alt="" should be used |
| 10:57 | hsivonen | wonders how many times in his life he will end up writing new line normalization |
| 10:57 | <hsivonen> | ooh. all the wasted productivity on CRLF |
| 10:58 | <Lachy> | indeed. That's got to be one of the stupidest things that various protocol designers (FTP, HTTP, etc.) have ever made |
| 10:58 | <Lachy> | s/things/mistakes/ |
| 11:01 | <othermaciej> | you mean a requirement to handle all the various line ending permutations? |
| 11:03 | <Lachy> | not that they had to handle it, but that they handled it using CRLF instead of just LF. We can blame the system engineers before them that implemented CRLF and CR for line endings. |
| 11:03 | <hsivonen> | othermaciej: I mean having to write code to handle CRLF, LF and CR for the nth time |
| 11:04 | <othermaciej> | it's annoying but given the state of the world requiring exactly one of those options would probably lead to non-conformance and lack of interoperability |
| 11:05 | <othermaciej> | I blame the implementors of DOS and the original Macintosh System for not seeing that LF is the one true path |
| 11:05 | <Lachy> | othermaciej, yeah, we can't change it now, but CR should never have existed |
| 11:05 | <hsivonen> | othermaciej: yeah |
| 11:14 | <Lachy> | othermaciej, did you update Degrade Gracefully, but forget to check in the changes? |
| 11:18 | <othermaciej> | Lachy: I thought I verified that the new version was on the web site, but let me double check |
| 11:18 | <Lachy> | oh, never mind, it was cached |
| 11:18 | <othermaciej> | I like the way the rewritten versions of the principles are coming out but it's a lot of work |
| 11:18 | <Lachy> | the original design principles were intended to be short, clear and concise statements. The rewrites are becoming significantly more verbose. |
| 11:21 | <othermaciej> | yes |
| 11:21 | <othermaciej> | but I think they will also be more enlightening to people who didn't already have them as implicit assumptions |
| 11:22 | <Lachy> | given the parsing behaviour of existing browsers, using section { display: block } is really only effective in XHTML5 |
| 11:23 | <Lachy> | sadly, graceful fallback for new block elements in HTML5 isn't all that great, but there's little that can be done about it |
| 11:23 | <othermaciej> | I guess I should remove that example then |
| 11:24 | <othermaciej> | I guess if you nest blocks inside it gets split by residual style handling? |
| 11:24 | <hober> | with <section><div>...</div></section> they end up as sibling elements, IIRC |
| 11:25 | <othermaciej> | hmm |
| 11:25 | <Lachy> | yes, though, that's not really a problem unless you also try to do: section { background: green; } |
| 11:25 | <Lachy> | or similar |
| 11:25 | <othermaciej> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Csection%3E%0A%3Cdiv%3ETest.%3C%2Fdiv%3E%0A%3Cp%3EThis%20is%20also%20a%20test.%3C%2Fp%3E%0A%3C%2Fsection%3E%0A%0A |
| 11:25 | <Lachy> | it is a problem if you want to use selectors like: section section h1 { ... } |
| 11:26 | <othermaciej> | seems to work as I expect in Safari |
| 11:26 | <othermaciej> | (in my current trunk build, anyway) |
| 11:26 | <Lachy> | that's because Safari is too good. Check FF and IE |
| 11:26 | <Lachy> | current release versions |
| 11:26 | <othermaciej> | I get siblings in Firefox though |
| 11:26 | <Lachy> | works for Safari 3 beta (Win) |
| 11:27 | <hsivonen> | hmm. the Feed Validator doesn't even try do source highlighting with finer than line granularity... |
| 11:27 | <othermaciej> | Firefox helpfully adds a _moz-userdefined="" attribute too |
| 11:27 | <hsivonen> | a highlight can span a line break in my design (since a tag can) |
| 11:27 | <othermaciej> | Opera also nests as I expected |
| 11:28 | <hsivonen> | which means I want pre handling for line breaks instead of one <li> per line |
| 11:28 | <Lachy> | hsivonen, is your validator's show source feature going to have a pretty print feature? |
| 11:28 | <othermaciej> | I guess I need to take that example out though |
| 11:28 | <hsivonen> | Lachy: I wasn't planning to pretty print |
| 11:28 | <othermaciej> | but not right now, 'tis sleepytime |
| 11:28 | <hsivonen> | Lachy: I was planning on dumping the source and the parse tree |
| 11:28 | <hsivonen> | Lachy: but not pretty-printed source |
| 11:29 | <Lachy> | ok |
| 11:29 | <hsivonen> | (preserving error positions before and after pretty printing is a problem I'd rather avoid solving |
| 11:29 | <Lachy> | so if you were to highlight entire lines, it wouldn't be particularly useful for input that uses long lines |
| 11:29 | <hsivonen> | Lachy: right |
| 11:30 | <hsivonen> | Lachy: which is why I want more granularity |
| 11:30 | <hsivonen> | but HTML doesn't do overlapping ranges (except in IE :-) |
| 11:30 | <hsivonen> | so I don't know how I could mark a range that spans a line break *and* have one <li> per line for line numbering |
| 11:31 | <Lachy> | <li>aaa<m>bbb</m></li><li><m>ccc</m>ddd</li> |
| 11:32 | <Lachy> | that'll work well enough |
| 11:32 | <hsivonen> | Lachy: not with the :target selector :-( |
| 11:33 | <hsivonen> | what's the CSS situation with making white space significant (including breaks) but allowing line wrapping? |
| 11:34 | <Lachy> | I assume both lines would be highlighted, but the :targeted line would be in a diff colour? |
| 11:34 | <Lachy> | like the IRC logs? |
| 11:34 | <Lachy> | white-space: pre-wrap; works in some browsers |
| 11:35 | <hsivonen> | does "some" include IE? what about WebKit/Gecko/Opera? |
| 11:35 | <krijnh> | Whuh, whah? |
| 11:35 | <krijnh> | IRC logs? |
| 11:35 | <Lachy> | see the styles used in the W3C list archive. e.g. this random post http://lists.w3.org/Archives/Public/www-archive/2007Aug/0082.html - they use various proprietary alterntives |
| 11:35 | <hsivonen> | simple problems are surprisingly complicated when you start implementing |
| 11:36 | <Lachy> | krijnh, I was referring to the yellow highligting for important lines and orange for :target |
| 11:37 | <hsivonen> | Lachy: that one has -moz-pre-wrap |
| 11:37 | <hsivonen> | pre { |
| 11:37 | <hsivonen> | white-space: pre-wrap; /* css-3 */ |
| 11:37 | <hsivonen> | white-space: -moz-pre-wrap; /* Mozilla, since 1999 */ |
| 11:37 | <hsivonen> | white-space: -pre-wrap; /* Opera 4-6 */ |
| 11:37 | <hsivonen> | white-space: -o-pre-wrap; /* Opera 7 */ |
| 11:37 | <hsivonen> | word-wrap: break-word; /* Internet Explorer 5.5+; makes the CSS invalid :( */ |
| 11:37 | <hsivonen> | } |
| 11:37 | <hsivonen> | cute |
| 11:38 | <krijnh> | white-space: -hp-pre-wrap; /* HP printers */ |
| 11:39 | <Lachy> | krijnh, does that really work? |
| 11:39 | <krijnh> | (from http://ln.hixie.ch/resources/style/spaced.css ) |
| 11:40 | <krijnh> | Sorry, I'm just dropping in the discussion, I'll leave again now :) |
| 11:40 | <hsivonen> | do people care about visible line numbers if you can address an error position by fragment id? |
| 11:40 | <Lachy> | hsivonen, yes |
| 11:41 | <hsivonen> | Lachy: :-( |
| 11:41 | <Lachy> | line numbers make it possible to then look up that line in their editor |
| 11:41 | <hsivonen> | Lachy: oh, the error messages would have numbers |
| 11:41 | <hsivonen> | Lachy: I mean does the source dump need to show them? |
| 11:42 | <Lachy> | it is convenient. That's what we need a ::line pseudo-element for to add line numbers without explicit markup |
| 11:44 | <annevk> | XBL |
| 11:44 | annevk | is for less pseudo-elements and more generic solutions |
| 11:44 | <Lachy> | ooh, that would be a good example to do in the primer! |
| 11:45 | <Lachy> | but I'm not sure how it could work |
| 11:46 | <annevk> | a simple script |
| 11:46 | <annevk> | split on \n and put it in <li> or something |
| 11:46 | <annevk> | although you still need some API to change selection behavior and such |
| 11:46 | <annevk> | well, a simpler one |
| 11:47 | <Lachy> | that would also split the <m> elements |
| 11:48 | <annevk> | hmm, if trey're used multiline I suppose you have to make it slightly more advanced |
| 11:48 | <annevk> | (that's a good reason not to add ::line fwiw) |
| 11:49 | <hsivonen> | annevk: there's already first-line that does styling in a way that doesn't match the underlying tree |
| 11:49 | <Lachy> | only if you care about implementation complexity for browsers :-) |
| 11:50 | Lachy | doesn't have to care about that stuff for at least another 2 weeks |
| 11:51 | <Lachy> | (till I start at Opera, then such things will matter for me) |
| 11:51 | <annevk> | hsivonen, yes, and ::first-letter, they're annoying |
| 11:51 | <annevk> | (and underdefined for those specific cases of course) |
| 11:52 | Lachy | --> dinner, bbl |
| 11:53 | annevk | reads a funny discussion on the longdesc= debate |
| 11:54 | <hsivonen> | is there a nice way to capture fragment id changes in JS? |
| 11:54 | <hsivonen> | I guess I could use few lines of JS instead of :target |
| 11:55 | <annevk> | setTimeout() |
| 11:55 | <annevk> | HTML5 introduces hashchanged |
| 11:55 | <Lachy> | capture the click event for links and update |
| 11:59 | <hsivonen> | eww. setTimeout() can't be right |
| 11:59 | <Lachy> | hmm. window.watch('location', myHandler); won't work now :-( http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:Object:watch |
| 12:00 | <annevk> | hsivonen, just add an onclick= to all the links for which you want the effect |
| 12:02 | <virtuelv_> | hsivonen: while not right, it 'works' |
| 12:03 | <Lachy> | virtuelv_, it may work, but extremely inefficient |
| 12:03 | <zcorpan> | document.onclick = ... |
| 12:04 | <virtuelv_> | Lachy: sort of right |
| 12:04 | <virtuelv_> | what hsivonen wants is not an expensive operation |
| 12:04 | <annevk> | you need setTimeout() for real btw |
| 12:04 | <annevk> | otherwise you're not handling history traversel, bookmarks to the link, etc. |
| 12:06 | <Lachy> | maybe, but you'd still be polling the value every X milliseconds, where X is short enough to not provide a significant delay when the value really changes |
| 12:08 | <annevk> | 200 worked for me |
| 12:08 | annevk | uses it in http://anne.is.weggeweest.nl/image-viewer |
| 12:11 | <Lachy> | annevk, looks like it uses 2000 |
| 12:11 | <zcorpan> | ooh, <area alt> sort of works in O9.5a |
| 12:11 | <annevk> | oops, you want setInterval |
| 12:12 | <Lachy> | oh, I see |
| 12:12 | <hsivonen> | virtuelv_: ok |
| 12:13 | <Lachy> | ah, \setTimeout is used for the automatic slide show |
| 12:15 | <virtuelv_> | I remember, back in the bad old days when one had to use setTimeout to emulate onresize |
| 12:17 | <virtuelv_> | (Can't remember if it was for Opera or Netscape, though) |
| 12:23 | <annevk> | (I stole my technique from http://w3future.com/weblog/stories/2002/05/04/urisForDynamicPages.xml by the way. It's surprisingly simple.) |
| 13:27 | <annevk> | interesting data from the German guy |
| 13:29 | <annevk> | anyway, time to go for the rest of the weekend |
| 13:41 | <Lachy> | that is indeed a very interesting conclusion. It'll be interesting to see the responses from those in favour of keeping longdesc |
| 13:49 | <Lachy> | I wonder if the the cite attribute for blockquote should be given the same treatment as longdesc. i.e. drop it because a) it's not usefully implemented and b) <cite><a href=""> is more effective. |
| 13:52 | <zcorpan> | Philip`, Hixie: we need a survey about whether <img usemap> have useful alt text (on the image itself) often enough to make it useful to show to the user... (though i don't know how to perform such a survey, perhaps manual checking of some random pages that have image maps with non-empty alt is required) |
| 13:52 | <zcorpan> | s/need/want/ :) |
| 13:53 | <stelt> | Services working on files usually have both a file upload and a text field for URL. As web and local are mixing, what about combining these 2 form fields into one as well ? (i did a bit of javascript coding to simulate it) |
| 13:54 | <Lachy> | stelt, please explain what you mean? |
| 13:54 | zcorpan | looks at http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/tagattr/img/usemap |
| 13:57 | <Philip`> | "useful alt text" is unfortunately hard to determine automatedly :-( |
| 13:58 | <Lachy> | Philip`, you just need to write some better artificial intelligence! |
| 13:58 | <Philip`> | Is it worth looking for a list of <img alt usemap>, or is it fine to just manually check all the <img usemap> uses for ones with alt? |
| 13:59 | <zcorpan> | i've looked at the first 4 in http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/pages/tagattr/img/usemap although they all had no alt at all |
| 14:00 | <zcorpan> | so it would be useful to have a list of pages that have <img usemap> with a non-empty alt attribute |
| 14:01 | <zcorpan> | or at least have an alt attribute |
| 14:01 | <Lachy> | Philip`, on the results page, could you show the images and alt text besides each other to make it easier to examine them |
| 14:02 | <Lachy> | it might be worth looking at the <area alt=""> of the associated image map too, if possible. |
| 14:03 | <stelt> | Lachy, instead of <input type="text" name="url"> and <input type="file"> (for either local or remote file) i'd sometimes just like something like <input type="local_or_remote"> |
| 14:03 | <stelt> | i sort of simulated this with 1 <input type="text"> and |
| 14:03 | <stelt> | <div id="data" style="z-index:2;visibility:hidden;"> |
| 14:03 | <stelt> | file |
| 14:03 | <stelt> | <input name="data_file" id="datadata_file" type="file" onchange="return divInputChange('data','file',this.value);"> |
| 14:03 | <stelt> | <br><br>or URL |
| 14:03 | <stelt> | <input name="data_url" id="data_url" type="text" onchange="return divInputChange('data','url',this.value);"> |
| 14:03 | <stelt> | </div> |
| 14:03 | <zcorpan> | first page with an alt attribute: http://www.harrahs.com/casinos/harrahs-atlantic-city/hotel-casino/property-home.shtml -- alt="brand_bar" |
| 14:03 | <zcorpan> | not useful |
| 14:06 | Philip` | tries implementing the rules for parsing a hashed ID reference |
| 14:06 | <Lachy> | stelt, could you link to a useful example that demonstrates what you're trying to achieve? |
| 14:07 | <Lachy> | stelt, or fix the example you gave earlier. |
| 14:07 | <Lachy> | stelt, http://html5.lachy.id.au/?type=text%2Fhtml%3B+charset%3DUTF-8&data=%3Cdiv+id%3D%22data%22+style%3D%22z-index%3A2%22%3E%0D%0Afile+%3Cinput+name%3D%22data_file%22+id%3D%22datadata_file%22+type%3D%22file%22+onchange%3D%22return+divInputChange%28%27data%27%2C%27file%27%2Cthis.value%29%3B%22%3E%0D%0A%3Cbr%3E%3Cbr%3Eor+URL%0D%0A%3Cinput+name%3D%22data_url%22+id%3D%22data_url%22+type%3D%22text%22+ |
| 14:07 | <Lachy> | onchange%3D%22return+divInputChange%28%27data%27%2C%27url%27%2Cthis.value%29%3B%22%3E%0D%0A%3C%2Fdiv%3E |
| 14:07 | <zcorpan> | http://www.sil.org/computing/comp-morph-phon.html -- ALT="See Text Menu" ... hmm, denotes that it is a menu |
| 14:08 | <zcorpan> | although most client side image maps seem to be menus |
| 14:08 | <stelt> | Lachy, for example the W3C validator has separate forms for file upload and on-line files, if there was 1 input flavour that combines both into 1 it would make it a lot easier for both coder and user |
| 14:10 | <Lachy> | stelt, I don't see how a combined control would make that easier for developers. I'd like to see a functioning example of the JS solution you mentioned |
| 14:11 | <Lachy> | stelt, use that page I linked to before, write the markup and script, click "upload" to upload it to the clipboard when you're done and let me know |
| 14:11 | <zcorpan> | the w3c validator interface wouldn't really need separate forms, it could have one form with multiple fields for the input document |
| 14:11 | <zcorpan> | like e.g. http://software.hixie.ch/utilities/cgi/data/data |
| 14:12 | <stelt> | zcorpan, when you have a service that has a file for many parameters it will get you an ugly UI ... |
| 14:12 | <Lachy> | stelt, do you have a site somewhere that needs this feature? |
| 14:12 | <Lachy> | if so, provide a link |
| 14:13 | <zcorpan> | stelt: you could spice up the ui to be just like the w3c validator while still having one form |
| 14:14 | <stelt> | Lachy, i'm working on such a site |
| 14:48 | <Philip`> | zcorpan, Lachy: http://canvex.lazyilluminati.com/misc/imgmaps.xhtml shows images which have usemap and alt attributes, where the usemap points to an existent map |
| 14:50 | <Philip`> | (I only found one usemap syntax error (usemap="0") and two where I couldn't find the matching <map>) |
| 14:51 | <Philip`> | (...and 140 correct ones, from 1024 pages) |
| 14:51 | <Philip`> | ((I can look at more pages trivially - it only took a minute to run)) |
| 14:52 | <zcorpan> | Philip`: thanks! |
| 14:53 | <zcorpan> | Philip`: wow, that's really useful |
| 14:55 | <Lachy> | Philip`, that's awesome! |
| 14:56 | <Lachy> | #map21 is a nice one :-) |
| 14:56 | <Lachy> | Philip`, can you add numbers to the table to help identify them? |
| 15:00 | <zcorpan> | http://simon.html5.org/temp/usemap-alt.txt |
| 15:00 | <virtuelv_> | 1024 pages is a small sample, though |
| 15:02 | <zcorpan> | virtuelv: yeah, but they need manual investigation anyway |
| 15:03 | <zcorpan> | seems like supressing alt would be a good thing in some cases and a bad thing in others |
| 15:03 | <Philip`> | Lachy: Updated so it's numbered |
| 15:04 | <Philip`> | See e.g. http://canvex.lazyilluminati.com/misc/imgmaps.xhtml#10 |
| 15:04 | <zcorpan> | it would be possible to catch some of the first by checking if there's exactly one area and it has same alt as the image |
| 15:05 | <Philip`> | If anybody wants more stuff to read through manually, I'm happy to do a larger sample since it doesn't require any effort :-) |
| 15:06 | zcorpan | is happy with the current sample :) |
| 15:08 | <zcorpan> | e.g. #4, #29, #110 |
| 15:08 | <zcorpan> | though that case is not very common and it wouldn't be very annoying to use both |
| 15:09 | <zcorpan> | overall it seems useful to never supress the image's alt |
| 15:36 | <Lachy> | #10 interesting "[English Flag - click here for English version]" with a picture of the US flag |
| 15:37 | <Lachy> | it has effectively the same meaning, though still innaccurate |
| 16:28 | <Lachy> | I wrote some instructions for posting to the blog http://blog.whatwg.org/submit-article |
| 17:11 | <Philip`> | Ooh, APNG in Opera |
| 17:12 | <Philip`> | (That makes it more useful to draw auto-animated images in <canvas> than when you could only do animated GIFs) |
| 17:15 | <virtuelv_> | Philip`: I'm not convinced canvii should accept animated images |
| 17:16 | <Philip`> | It'd make the sprites on http://canvex.lazyilluminati.com/83/play.xhtml easier to implement |
| 17:17 | <Philip`> | (and save bandwidth, since most of the frames are the same) |
| 17:17 | <virtuelv_> | yeah, but what should happen with the different composite modes? |
| 17:18 | <Philip`> | Why would it be any different to drawing a static image, except that it uses the current frame at the time when you call drawImage? |
| 17:19 | <virtuelv_> | would require browsers to store the rectangle covered by the canvas |
| 17:20 | <virtuelv_> | s/canvas/image/ |
| 17:20 | <virtuelv_> | not saying it can't be done, but it puts a toll on implementations |
| 17:21 | <Philip`> | I don't want the canvas output to ever change automatically, since that sounds probably crazy and complicated - I'm imagining that you'd still have to manually redraw the screen for every frame, but drawImage would automatically pick the current animation frame each time you call it |
| 17:22 | <Philip`> | (which is what Firefox does, if I remember correctly) |
| 17:36 | <virtuelv_> | anyway, how animated images behave should go into the spec |
| 17:39 | <Philip`> | (Drawing animated SVG into a canvas is a more fun problem :-) ) |
| 17:44 | <virtuelv_> | drawing SVG into a canvas is a useful means to get canvas text |
| 18:29 | <gsnedders> | how is application/octect-stream sniffed? |
| 18:31 | <chrismurf> | what's the correct way to do dotted / dashed / etc. lines with canvas strokes? I expected strokeStyle, but that seems to be just color. Should I just draw/move/draw/move/draw/move (yuck) ? |
| 18:35 | <Philip`> | chrismurf: Currently the only way is to manually draw lots of short lines |
| 18:35 | <chrismurf> | Philip`, thank you. If you're Philip Taylor, I was just stumbling on your notes on html5.org on this topic |
| 18:36 | <Philip`> | http://canvex.lazyilluminati.com/misc/dash.html implements it in a slightly generic and not entirely bug-free way |
| 18:36 | <chrismurf> | sorry for not finding it sooner |
| 18:36 | <chrismurf> | oh - that's perfect |
| 18:36 | <Philip`> | That is me :-) |
| 18:36 | <chrismurf> | generic and not entirely bug-free is better than non-existent and buggy, which is what I would have ;-) |