| 01:14 | <Philip`> | Hmm, Nvu appears to emit <comment> elements |
| 01:14 | <Philip`> | (See e.g. http://nehafruits.com/Index.html ) |
| 01:15 | <Hixie> | good times |
| 09:17 | <hsivonen> | I think I'm going to implement alt *warnings* with adaptive messages depending on a guess based on width and height. |
| 09:17 | <hsivonen> | Does anyone have a reason why this is a bad idea? |
| 09:18 | <Dashiva> | It will incur the wrath of the semanticists? |
| 09:18 | <MikeSmith> | hsivonen, not sure that you mean by adaptive messages depending on a guess on width and height |
| 09:19 | <hsivonen> | MikeSmith: warning about every badge-size altless image but whining once per page about photo-sized altless images |
| 09:19 | <hsivonen> | you'd still get at least one warning per page with at least one altless image |
| 09:19 | <hsivonen> | but you wouldn't get a warning for each probable photo |
| 09:21 | <hsivonen> | since warning don't affect the overall outcome, it is OK for warnings to be based on guesses |
| 09:21 | <MikeSmith> | yeah, that sounds reasonable |
| 09:24 | <MikeSmith> | hsivonen, I'm wondering if you're considering having an option in the UI to turn on or tune the warning level for alt |
| 09:24 | <MikeSmith> | to me, that's something that would potentially raise author awareness of alt more than making it always-required |
| 09:24 | <hsivonen> | MikeSmith: I'm considering it, but I want to avoid UI options when they can be avoided |
| 09:25 | <MikeSmith> | Yeah, I can understand that |
| 09:25 | <hsivonen> | good point |
| 09:25 | <MikeSmith> | slippery slope |
| 09:26 | <annevk> | I'd always give a single warning I think |
| 09:45 | <jgraham_> | I wonder if there's a decent way to collect useful data about the way @alt is used. I'm thinking maybe a browser extension that takes you to a random page, displays the page with images and CSS off and then displays each image and asks various questions about the corresponding alt text |
| 09:45 | <jgraham_> | like whether it is useful. Maybe also what type of image |
| 09:46 | <hsivonen> | Hixie: btw, I think WCAG 2.0 is rather reasonable about the inkblot case and the HTML5 example takes "alternative" too literally |
| 09:46 | <jgraham_> | Then collect that data together with automatically extracted data (what are the image's dimensions?) on a central server |
| 10:04 | <annevk> | http://webbstandard.se/2008/04/allt-utom-mojligen-diskbanken.html |
| 10:05 | <annevk> | given the quotes from the Borg I assume it's not a positive remark? :) |
| 10:11 | <hsivonen> | annevk: it's basically complaining about lack of versioning and modularization and building a monolithic kitchen sink language instead |
| 10:12 | <webben> | jgraham: I believe a rudimentary study of that sort was already done by Manu Sporny on the microformats list. |
| 10:16 | <webben> | jgraham: http://microformats.org/discuss/mail/microformats-new/2007-July/000629.html |
| 10:17 | <webben> | jgraham: It may be it failed to consider whether the alt text was appropriate in context however. |
| 10:20 | <webben> | I did raise that point in subsequent discussion; can't now remember how that was clarified |
| 10:22 | <jgraham_> | webben: Interesting, but it does look (on first glance) like their method was totally broken |
| 10:22 | <jgraham_> | because, as you note, they seem to be assuming @alt is supposed to be a description for the image |
| 10:23 | <jgraham_> | rather than an in-context replacement |
| 10:24 | <jgraham_> | and I can't see a reply to the post where you raise this flaw |
| 10:26 | <webben> | neither can I; I think discussion of the study was in several threads however; Tantek does raise it. |
| 10:26 | <webben> | http://microformats.org/discuss/mail/microformats-new/2007-July/000635.html |
| 10:27 | <webben> | http://microformats.org/discuss/mail/microformats-new/2007-July/000628.html |
| 10:27 | <webben> | (me) |
| 10:28 | <webben> | I seem to have raised the point in preceding discussion. |
| 10:28 | <jgraham_> | Yeah, this all confirms that it should be done again, presenting the _whole_ page to the user (minus the images, or maybe just minus the current image) and letting them assess the alt text one image at a time |
| 10:29 | jgraham_ | has to go now |
| 10:29 | <webben> | laters |
| 10:30 | <Philip`> | Why not just show all the images and use a img:before{content:attr(alt);background:magenta} then count how many of the alts make sense in context and correspond to their image? |
| 10:31 | <annevk> | :before / :after and replaced elements is sort of a complex thingie |
| 10:32 | <Philip`> | Or write a script to create adjacent text nodes with the alt text, or whatever |
| 10:33 | <jgraham_> | Philip`: That might work for display but it would be nice to collect other information like the type of the image (photo/icon/advert/etc.), the context (is is in a link?) and a qualitative assessment of the goodness of the alt text so just counting seems inadequate |
| 10:34 | jgraham_ | really is going now |
| 11:55 | Philip` | saw a nice cat carrying a cute little mouse in its mouth, presumably to take it home and have a cup of tea and some biscuits together, but sadly it dropped the mouse when approached and the mouse ran away :-( |
| 11:55 | <Philip`> | (Alternative interpretation: cats are vicious carnivores) |
| 12:09 | <MikeSmith> | Philip`, another alternative interpretation: It was a smart but lazy mouse who tricked the cat into giving him a free ride for a few blocks |
| 12:10 | <jruderman_> | lol |
| 12:13 | <Lachy> | hmm, it seems IE8 may have intentionally violated the selectors api spec :-( |
| 12:14 | <Lachy> | they apparently ignore selctors with the :link pseudo-class, so .querySelector(":link") won't match anything |
| 12:15 | <Lachy> | at least according to their white paper about it. http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=574 |
| 12:15 | <Lachy> | I'm currently trying to get it installed on my work machine to test it |
| 12:33 | <Lachy> | anyone know why IE8 doesn't work with the live dom viewer? |
| 12:40 | <zcorpan> | Lachy: enumerating the attributes doesn't work for some reason |
| 12:41 | <zcorpan> | Lachy: there's /ie8.html though |
| 12:45 | <jruderman_> | Lachy: i think IE does the right thing there |
| 12:46 | <webben> | Philip`: There are plenty of existing tools that can show alt text beside images, if that's all you want. |
| 12:46 | <webben> | most of the webdev and accessibility toolbars can do that I think |
| 13:06 | hsivonen | needs some kind of Base64 padding for dummies guide |
| 13:09 | <Philip`> | Lachy: Because they unimplemented Node.attributes |
| 13:12 | <Philip`> | Lachy: http://software.hixie.ch/utilities/js/live-dom-viewer/ie8.html works instead |
| 13:13 | <Philip`> | Oh |
| 13:13 | <Philip`> | zcorpan already said that :-( |
| 13:13 | <Philip`> | (http://blogs.msdn.com/ie/archive/2008/04/10/html-and-dom-standards-compliance-in-ie8-beta-1.aspx - "Known issues we are planning to address in Beta 2: ... <element>.attributes.length fails. The IE8 NamedNodeMap object is in the middle of an overhaul.<element>.attributes.length fails. The IE8 NamedNodeMap object is in the middle of an overhaul.") |
| 13:14 | <Philip`> | s/(.+)\1/$1/ |
| 13:15 | <Lachy> | thanks |
| 13:20 | <Lachy> | crap, IE's selectors api implementation is really bad. |
| 13:20 | <Philip`> | In what ways? |
| 13:21 | Philip` | hopes there is a test suite that they can fail |
| 13:21 | <Lachy> | these don't work properly: querySelector(":link"), querySelector(""), .querySelector(null); |
| 13:21 | <Lachy> | although, that last one isn't really defined well in the spec |
| 13:22 | <Lachy> | I started working on the test suite today, figuring out exactly what needs to be tested and how to test it |
| 13:23 | <Philip`> | Maybe they didn't want to bother changing their CSS implementation so that :visited could be matched by :link in certain cases (like when used via the Selectors API), so they just banned both of those selectors since it was easier |
| 13:23 | <Philip`> | I'm not sure why else they wouldn't just make :link match all links |
| 13:25 | Philip` | suggests writing the test suite with YAML and Python :-) |
| 13:25 | <Lachy> | I don't know YAML |
| 13:27 | <Philip`> | It's trivial to learn :-) |
| 13:27 | <Philip`> | You write "key: value" for a hash/dict/whatever data structure, and "- stuff" for an array item, and you indent things appropriately, and that's often all you need |
| 13:29 | <Philip`> | Or you could be really boring and write the test cases in something ugly and verbose like HTML or XML |
| 13:30 | <Lachy> | well, each test needs to have a script that uses querySelector*() and associated markup. How could that be written using YAML? |
| 13:32 | <Philip`> | I did stuff like http://philip.html5.org/tests/canvas/suite/tests2d.yaml giving various data (name, spec points being tested, etc) and the JS code to run and (optionally) Python code to generate the image of the expected output |
| 13:33 | <Philip`> | and then a Python script generates the expected output image and converts the @assert lines into proper JS code and creates the HTML files for each test |
| 13:34 | <Philip`> | mostly so that I can minimise the amount of boilerplate code in the files that I have to edit |
| 13:36 | <Lachy> | nice. |
| 13:36 | <Lachy> | Can I get a copy of your python script? |
| 13:36 | <Philip`> | http://philip.html5.org/tests/canvas/suite/gentest.py |
| 13:36 | <Philip`> | It's all totally ad hoc and hacked together for this specific purpose, so it might not be very useful |
| 13:37 | <Lachy> | at least it's a starting point for me though |
| 13:37 | <Philip`> | (http://philip.html5.org/tests/canvas/suite/source.tar.bz2 has all the files) |
| 13:38 | <Philip`> | (and only a few bugs that make it not actually work) |
| 13:43 | <Philip`> | http://www.w3.org/Style/CSS/Test/guidelines.html#format just has too much stuff to copy-and-paste into each file |
| 13:43 | <Philip`> | and also I much prefer having a single file to edit, rather than six hundred |
| 14:11 | <hsivonen> | Lachy: data URI support in V.nu deployed |
| 14:12 | Philip` | finds it annoying that typing something into the Address box then pressing 'enter' does not submit the form |
| 14:12 | <Philip`> | ...in Opera 9.2 in particular |
| 14:13 | <Philip`> | Hooray for WF2 |
| 14:13 | <Philip`> | Opera says "data:text/html,hello world is not a legal URI" and refuses to submit the form |
| 14:13 | Philip` | switches to a browser which has fewer features and therefore works much better |
| 14:14 | <Philip`> | hsivonen: http://validator.nu/?doc=data%3Atext%2Fhtml%2Chello+world has an IO Error |
| 14:15 | <hsivonen> | Philip`: that for QA :-) |
| 14:15 | <hsivonen> | s/that/thanks/ |
| 14:16 | <Lachy> | Philip`, are you sure spaces are allowed in a URI like that? Shouldn't they be encoded as %20? |
| 14:16 | <hsivonen> | (of course, I only tested with ;charset=utf-8) |
| 14:17 | <Philip`> | Lachy: I'm not sure but I don't care since it works anyway |
| 14:20 | <Lachy> | Philip`, the problem is with validator.nu, since the markup contains pattern="(?:https?://.+)?" |
| 14:20 | <Philip`> | Oh, right, I assumed it was just doing type=url or something |
| 14:20 | <Lachy> | has support for data URIs been added to the validator yet? |
| 14:21 | <Philip`> | Lachy: "14:16 < hsivonen> Lachy: data URI support in V.nu deployed" indicates yes |
| 14:21 | <hsivonen> | Philip`: fixed. |
| 14:21 | <Lachy> | hsivonen, fix the pattern attribute |
| 14:21 | <Lachy> | good |
| 14:22 | <hsivonen> | Lachy: thanks. I was testing in Firefox and Safari... |
| 14:23 | <Philip`> | WF2 doesn't pass the write-new-code-and-only-test-in-legacy-browsers test |
| 14:23 | <Lachy> | that illustrates the problem with using features that aren't supported by the tools you're using, since you fail to encounter any problems in tools that do support them |
| 14:23 | <Philip`> | Input validation needs a "I don't care, submit this form anyway" feature |
| 14:24 | <Philip`> | hsivonen: (The title="Absolute IRI (http or https only) of the document to be checked." should be updated too) |
| 14:24 | <Lachy> | Philip`, that would be difficult to implement for cases where scripts capture the form validation events for custom processing |
| 14:28 | <Philip`> | Hixie: See above - WF2 is rubbish because browsers that support it work worse than browsers that don't |
| 14:30 | <Lachy> | Philip`, it's not a major problem yet, because there are very few early adopters of WF2. |
| 14:30 | <Philip`> | Lachy: It will become a more major problem in the future, if nothing is done to solve it |
| 14:31 | <Lachy> | the solution is to get more browsers to implement, and not encourage people to use it until they are testing in browsers that do support it |
| 14:31 | <Philip`> | If e.g. Firefox implemented it, I imagine it would become far more widely used, and then people would copy-and-paste WF2-using code into their own pages and only test in IE and publish it and everyone will be unhappy |
| 14:32 | <Philip`> | The only solution is to get *all* (major) browsers to implement it, and to get all users to upgrade to the new versions |
| 14:32 | <Lachy> | no, every browser needs to begin supporting it simultaneously, and all users and developers need to upgrade at the same time |
| 14:32 | <Philip`> | since people will do crazy things regardless of what encouragement you try to give |
| 14:32 | <Philip`> | so people are a lost cause, and we can only affect browsers |
| 14:34 | <Lachy> | browsers are a lost cause too, so we can only affect the spec :-) |
| 14:36 | <Philip`> | (I was surprised by how many web pages use chrome:// URIs, because they've somehow copied code generated by Firefox extensions into their own pages) |
| 14:36 | <hsivonen> | Lachy: fixed |
| 14:37 | <hsivonen> | Lachy: not that Opera blocks Philip`'s test for a different reason now |
| 14:37 | <hsivonen> | (space in IRI) |
| 14:40 | <Philip`> | hsivonen: http://validator.nu/?doc=data%3ATEXT%2FHTML%2Chello%2520world fails |
| 14:40 | <Philip`> | and HTTP says "The type, subtype, and parameter names are not case sensitive. For example, TEXT, Text, and TeXt are all equivalent." |
| 14:41 | <Philip`> | (Er, at least an old version does; a new version just says "The type, subtype, and parameter attribute names are case- insensitive") |
| 14:46 | <hsivonen> | Philip`: hmm. that fails over HTTP, too, I presume... |
| 14:46 | <hsivonen> | thanks |
| 14:47 | <Philip`> | hsivonen: http://validator.nu/?doc=http://www.eastwestpr.com - yes |
| 15:21 | <Lachy> | Philip`, I'm trying to set up the appropriate systems for using YAML, but I just need to clarify exactly what I need to do... |
| 15:22 | <Lachy> | To install PySyck, do I have to install Syck separately? If so, I only found a source code tarball for it. Is compiling and installing from the source the only way to install it on Mac? |
| 15:24 | <Lachy> | do I need PyCairo? It was listed in your README file, but it seems to be a graphics library and I don't intend to create graphics |
| 15:24 | <Philip`> | I expect PySyck includes all the code it needs, rather than relying on an external library, but I don't really know |
| 15:24 | <Philip`> | and I know nothing about installing stuff on Macs except that it's a pain |
| 15:25 | <Lachy> | do you run everything on Windows? |
| 15:25 | <Philip`> | It's probably easier to use the more normal yaml module, rather than syck - I only wanted syck because I have a few hundred kilobytes of YAML and I'm lazy and don't want to wait seconds for the parser |
| 15:25 | <Philip`> | No, I run it on Linux |
| 15:26 | <Philip`> | PyCairo is only for generating graphics, which seems irrelevant for your needs |
| 15:26 | <Lachy> | The linux and mac setup should be quite similar |
| 15:26 | <Philip`> | (Compiling stuff on Windows is a pain too :-) ) |
| 15:27 | <Philip`> | The Linux setup is "emerge syck", which I don't think works on Macs |
| 15:27 | <Philip`> | (or I guess "apt-get install syck" or whatever, on other Linuxes) |
| 15:28 | <Lachy> | I got the yaml and html5lib stuff installed. They were easy. |
| 15:29 | <Lachy> | I'm pretty sure apt-get doesn't work on mac |
| 15:29 | <Philip`> | That's because Macs are rubbish :-) |
| 15:31 | <Lachy> | no, Macs are great. All linux distros I know of have exceptionally bad usability |
| 15:32 | <Philip`> | But Linux lets you say "apt-get install syck", which is far more usable than compiling and installing a source code tarball on OS X :-p |
| 15:33 | <Lachy> | the only reason I'm hesitant about running the commands that the readme file tells me to run is because I'm not sure what to do if something goes wrong with it |
| 15:34 | <Philip`> | There shouldn't be any need for syck, so it'd be fine to ignore it if it's not trivial to install |
| 15:43 | <Lachy> | ok, now I just need to learn how to write sufficient python for my needs, and lookup the documentation for the yaml and html5lib apis |
| 15:47 | <Philip`> | The yaml API is basically "data = yaml.load(open('stuff.yaml').read())", which returns a standard Python data structure with arrays and dicts |
| 15:47 | <Philip`> | or maybe it's "data = yaml.load(open('stuff.yaml'))" |
| 15:48 | <Lachy> | ok, that sounds easy |
| 15:48 | <Philip`> | html5lib is harder :-) |
| 15:48 | <Lachy> | I've used html5lib once before. |
| 15:48 | <Philip`> | but I'm not sure what you'll need it for |
| 15:48 | <Lachy> | it shouldn't be too hard to pick up if I need it |
| 15:49 | <Lachy> | I'm not sure either, but it was easy to install and useful to have |
| 15:49 | <Philip`> | I only use it for converting the HTML5 spec into XHTML so that gentest.py can quickly load it again and annotate it with test data |
| 15:49 | <Lachy> | I guess I should figure out exactly how to structure my YAML file |
| 15:50 | <Philip`> | I never figured out anything like that, I just added stuff that I found I needed in whatever way seemed easiest |
| 15:50 | <Philip`> | It's not a big software engineering project, so planning isn't that critical :-) |
| 15:51 | <Philip`> | (Hmm, gentest.py shouldn't actually import html5lib at all...) |
| 15:52 | <Lachy> | I know, but it's my first time using YAML ever, and I'd rather not just go for an ad hoc solution when I really have no clue what I'm doing |
| 15:52 | <Philip`> | (Oh, it doesn't, at least in my latest version) |
| 15:53 | <Philip`> | By the way, this YAML+Python method might be crazy and it'd be more sensible to just use XML or something |
| 16:03 | <Lachy> | what's so crazy about the YAML+Python method? |
| 16:14 | <Lachy> | JohnResig, yt? |
| 16:14 | <JohnResig> | Lachy: yep |
| 16:14 | <Lachy> | did you get my response about the selectors api test suite? |
| 16:15 | <JohnResig> | yeah, I was pulling together some links for you |
| 16:15 | <Lachy> | ok. I'm just wondering about which builds of Mozillla implement selectors api? |
| 16:15 | <Lachy> | if any |
| 16:15 | <JohnResig> | Lachy: we don't - here's the bug https://bugzilla.mozilla.org/show_bug.cgi?id=416317 |
| 16:16 | <Lachy> | ok, thanks |
| 16:17 | <JohnResig> | Lachy: I was going to point you at this: http://disruptive-innovations.com/zoo/css3tests/selectorTest.html#target |
| 16:18 | <Lachy> | ok. Put that, and anything else, in an email. |
| 16:18 | <JohnResig> | k |
| 16:19 | <Lachy> | I have to go to Norwegian lessons very soon, I'll be back later |
| 16:19 | <JohnResig> | k |
| 16:20 | <Lachy> | btw, those tests give a reasonable overview, but it doesn't seem particularly well constructed for determining exactly which tests are failing |
| 16:21 | <Lachy> | it seems more like an acid test |
| 16:21 | <Lachy> | though not as pretty |
| 16:21 | <JohnResig> | Lachy: just mouse over any test - the title describes it - although, using JavaScript, it'd be easy enough to dump that to a log |
| 16:22 | <Lachy> | oh, ok |
| 16:22 | <Lachy> | anyway, gotta go. cya |
| 17:48 | Philip` | finds a peculiarly translated blog post saying "The WS-Policy 1.5 - Framework writing crapper be accessed here.", which does not induce comfortable images |
| 19:27 | <BenMillard> | hsivonen_, you e-mailed public-html with this: "HTML 5 seeks to make layout tables non-conforming, which I think it is an exercise in futility." I've been thinking about defining what a layout table is in terms of which elements and attributes it does and does not use, so they could be told apart from data tables automatically |
| 19:27 | <BenMillard> | hsivonen_, something like "If a table contains <th>, scope or headers it is a data table. Otherwise it is a layout table." |
| 19:28 | <BenMillard> | layout tables which match the description for layout tables would be conforming; layouts tables which include <th>, scope or headers would not be conforming |
| 19:32 | <webben> | BenMillard: Looking for accessibility markup as a hint is nice in theory (it's the approach WCAG 1.0 was geared towards); I'm not sure it works that well in practice. |
| 19:32 | <webben> | (That is, I'm not sure how consistently data tables use any of that markup.) |
| 19:33 | <webben> | FWIW I think JAWS used to assume that outer tables were layout tables and inner tables were data tables. |
| 19:33 | <webben> | (when all it had was td anyhow) |
| 19:34 | <webben> | Given IE8's support for CSS table display properties, I'm not clear what the authoring advantages of layout tables would be anymore. |
| 19:35 | <BenMillard> | support legacy content and authoring convenience spring to mind |
| 19:36 | <webben> | so long as HTML5 defines how UAs treat layout tables, do you reckon people care about the conformance of legacy content? |
| 19:37 | <BenMillard> | I meant making legacy content work with ATs by having one interoperable method of detecting layout tables |
| 19:37 | <webben> | But that's not a conformance issue for authors; that's a conformance issue for UAs. |
| 19:37 | <webben> | Is that what we're talking about? |
| 19:38 | <webben> | If so, I hadn't realized HTML5 was insisting UAs treat table as data; that indeed wouldn't be very wise. |
| 19:39 | <webben> | If *not, I mean |
| 19:39 | <BenMillard> | http://sitesurgeon.co.uk/tables/ - 45% of the data tables I found don't use <th>; 35% use <td> for all their headers without scope or headers. telling authors their layout tables or data tables are broken seems useful for a checker |
| 19:40 | <webben> | Yes. |
| 19:40 | <BenMillard> | so there would be requirements for authors to follow the definitions and UAs to detect which tables fit which definition |
| 19:41 | <webben> | I'm not sure I can see authors combing over old table layouts to turn them into conforming layout tables. |
| 19:41 | <BenMillard> | "Outer tables can never be data tables." could be part of the definition |
| 19:41 | <webben> | I'd have thought it would be more useful to have a validator mode for checking all non-conforming markup is in a state that should "work". |
| 19:42 | <webben> | *more precise |
| 19:42 | <BenMillard> | the definition of layout tables would be informed by research into how they are currently authored; I'm just giving basic ideas for now :) |
| 19:42 | <webben> | then the few authors interested in converting old table layouts into working table layouts could use the tool like that |
| 19:43 | <webben> | likewise it could check over <applet> and any other things HTML5 considers beneath itself ;) |
| 19:43 | <BenMillard> | for authors, the idea would be to make working tables of either type conforming; broken tables of either type non-conforming |
| 19:44 | <webben> | BenMillard: I think one thing you need to factor into this is that the JAWS thing was practical because it worked for a general case; but you can switch between interpreting a given table as layout or data. |
| 19:45 | <webben> | That may be a more important facility for dealing with tables then the algorithm for guessing layout vs data. |
| 19:46 | <BenMillard> | that switch could be retained but the heuristics improved in HTML5 |
| 19:46 | <BenMillard> | so you wouldn't need to use the switch so much |
| 19:47 | <webben> | Well, yes, but making users use a switch isn't ideal; and making layout tables non-conforming supports their conversion to something that doesn't require a switch. |
| 19:48 | <BenMillard> | webben, these are useful points :) |
| 19:49 | <BenMillard> | but as you said, "few authors interested in converting old table layouts" mean big changes aren't going to happen in the legacy |
| 19:50 | <BenMillard> | if the layout table description is good enough, you won't need to use the switch because the detection will be right most or all of the time |
| 19:50 | <webben> | indeed. which is why I don't think authorial conformance requirements should be designed around people tweaking legacy markup. |
| 19:50 | <webben> | if. yes. |
| 19:50 | <webben> | guess you (or someone) needs to go give their best shot at an algorithm |
| 19:51 | <BenMillard> | yeah, I'm working on sponsorship to cover work like this |
| 19:51 | <webben> | but that still seems more about how UAs handle existing content than author conformance requirements |
| 19:51 | <webben> | (e.g. if you wanted to make it really easy for authors to indicate tables are for layout one could just have a layout attribute on table.) |
| 19:51 | <webben> | rather than requiring them to root through their th's |
| 19:51 | <BenMillard> | the idea is only a tiny number of layout tables would need changes |
| 19:52 | <BenMillard> | it will take research to figure out if legacy layout tables follow patterns consistently enough for this to be feasible :P |
| 19:52 | <webben> | I should imagine layout-table-forms vs. spreadsheet-table-forms would be a particularly painful area to try and spec out. |
| 19:55 | <BenMillard> | that's something I've been discussing on Accessify Forum recently (as Cerbera): http://www.accessifyforum.com/viewtopic.php?t=9791 |
| 19:56 | <BenMillard> | the UA part is at the end, summarised here: http://projectcerbera.com/blog/2008/04#day14 |
| 19:58 | <BenMillard> | would be cool if we can find a sane way for these things to Just Work natively |
| 19:59 | <webben> | yes. |
| 20:08 | <BenMillard> | zcorpan_, hi |
| 20:09 | <zcorpan_> | BenMillard: hi |
| 20:10 | <BenMillard> | zcorpan_, we've been talking about data tables, layout tables and tabular forms: http://krijnhoetmer.nl/irc-logs/whatwg/20080414#l-346 |
| 20:10 | <zcorpan_> | BenMillard: thanks, reading |
| 20:15 | <zcorpan_> | BenMillard: many layout tables use <th> |
| 20:16 | <zcorpan_> | BenMillard: and there are legitimate data tables with no <th> |
| 20:19 | <BenMillard> | zcorpan_, I'm not sure how many is many. <th> seems rare any place I've looked... |
| 20:20 | <BenMillard> | zcorpan_, a table with no headers is using layout to indicate relationships rather than labelling...so I'm not sure if that's a "legitimate" data table. |
| 20:20 | <BenMillard> | I don't have a concrete proposal for this, it's just an idea for now :) |
| 20:22 | <zcorpan_> | i don't have data about how many data tables use <th>, but i've seen several and <th> is a pretty common element in hixie's billion-document-study from 2005 |
| 20:23 | <BenMillard> | this headerless data table http://sports.espn.go.com/nhl/news/story?page=statistics/glossary should probably use <th> in the 1st column |
| 20:23 | <zcorpan_> | i don't consider a family tree <table> a layout table |
| 20:24 | <Philip`> | (I saw <th> on about 4% of pages) |
| 20:24 | <zcorpan_> | Philip`: and <td>? |
| 20:24 | <Philip`> | (and <table> on 74%) |
| 20:24 | <zcorpan_> | (ok) |
| 20:24 | <Philip`> | (and <td> on 0.2% fewer than <table>) |
| 20:27 | <zcorpan_> | Philip`: do you have a list of pages that use <th>? |
| 20:27 | <Philip`> | (and <tbody> on 0.2% in total) |
| 20:27 | <Philip`> | zcorpan_: http://canvex.lazyilluminati.com/survey/2007-07-17/analyse.cgi/pages/tag/th |
| 20:30 | <BenMillard> | zcorpan_, just viewed some family trees and see what you mean |
| 20:30 | <zcorpan_> | Philip`: thanks |
| 20:35 | <BenMillard> | zcorpan_, <ul> seems a better choice for the ancestor/sibling/descendant relationships in family trees, although I haven't check how that would look |
| 20:36 | <zcorpan_> | BenMillard: maybe, but it would make styling extremely non-trivial as to make it unrealistic |
| 20:37 | <zcorpan_> | in print, they are in a grid |
| 20:37 | <Philip`> | The strict tree model breaks down if your family has had some 'interesting' relationships |
| 20:37 | <BenMillard> | lol :D |
| 20:37 | <zcorpan_> | Philip`: that too, but that also makes it hard to do with <table> :P |
| 20:38 | <BenMillard> | display: table-* enjoying greater support might help? |
| 20:39 | <zcorpan_> | so the 5 first pages i've looked at with <th>, none of them had data tables |
| 20:40 | <zcorpan_> | BenMillard: can you make a demo page where nested <ul> displays like a proper grid with css? |
| 20:40 | <Philip`> | (My data is almost a year old so be careful that the pages haven't changed to be totally different nowadays) |
| 20:40 | <BenMillard> | zcorpan_, I'd like to do that and work on this properly but can't afford the time yet |
| 20:41 | <BenMillard> | just wanted to mention it here to get the cogs turning in other peoples' heads |
| 20:41 | <zcorpan_> | BenMillard: i've looked at making nested <ul>s show like a grid before but couldn't figure out a sane way to do it |
| 20:42 | <zcorpan_> | Philip`: i checked the source to confirm that they had <th |
| 20:42 | <zcorpan_> | (the first didn't) |
| 20:42 | <zcorpan_> | (so skipped it) |
| 20:43 | <zcorpan_> | the wikipedia page wasn't really a layout table, i guess, but it wasn't a data table either (it should have used <h3/><ul/> instead) |
| 20:44 | <BenMillard> | zcorpan_, if you can't do it then it must be impossible :) |
| 20:44 | <zcorpan_> | lol |
| 20:44 | <zcorpan_> | well it was quite a while ago |
| 20:45 | <zcorpan_> | perhaps i gave up too quickly and thought that <table> was the right way to do it |
| 20:45 | <zcorpan_> | (and i still think it is) |
| 20:48 | <BenMillard> | I remember your nested FIFA table was correctly laid out while my single <table> with several <tbody> was not |
| 20:51 | <zcorpan_> | (http://simon.html5.org/sandbox/html/fifa ) |
| 20:54 | <BenMillard> | the team names should be <th>? |
| 20:55 | <BenMillard> | (mine was http://sitesurgeon.co.uk/!dev/fifa2006/ben-millard.html) |
| 21:14 | <zcorpan_> | Hixie: should insertHTML use the html parser in xml documents too? |
| 21:27 | <Hixie> | zcorpan_: if you can find me a UA that uses an XML parser, I'm happy to switch it |
| 21:27 | <Hixie> | zcorpan_: my investigation suggested it was HTML all the way |
| 21:28 | <zcorpan_> | Hixie: last time i checked, opera always uses the html parser while firefox and webkit inserthtml only works in text/html |
| 21:29 | <Hixie> | k |
| 21:29 | <Hixie> | html it is then |
| 21:30 | <zcorpan_> | but it seems weird to have all the checks in the dom everywhere (like, say, setting dataset.foo) if inserthtml can insert anything in an xml document anyway |
| 21:31 | <Hixie> | zcorpan_: i put checks in dataset.foo? |
| 21:32 | <zcorpan_> | Hixie: "If setAttribute() would have raised an exception when setting an attribute with the name name, then this must raise the same exception." |
| 21:32 | <Hixie> | ah, ok, that's just setAttribute() then |
| 21:32 | <Hixie> | right, i basically set that up to be equivalent to setAttribute(), for ease of implementation |
| 21:32 | <zcorpan_> | that makes sense |
| 22:25 | <annevk> | hmm, CSS gradients |
| 22:27 | <roc> | I'm not all that enthusiastic about reinventing all of SVG in CSS |
| 22:27 | <annevk> | It does make sense though to have them in CSS... |
| 22:28 | <roc> | it makes some sense to have it all in CSS |
| 22:28 | <Philip`> | Lachy_: It's crazy because it's unconventional, particularly in the W3C world of XML, and also YAML is way too complex to be considered sane, and also writing single-purpose custom scripts seems an odd way to do a common task like publishing test suites |
| 22:28 | <Philip`> | (but I think it works well anyway, at least for me) |
| 22:29 | <annevk> | roc, true |
| 22:29 | <roc> | it's sort of like how the SVG people wanted to reinvent HTML+CSS text layout in SVG |
| 22:29 | <Lachy_> | Philip`, ok. I'm open to other suggestions, if anyone has any |
| 22:29 | <annevk> | I think they're still persuing the SVG application thingie... |
| 22:29 | <jgraham_> | Hmm, whilst I don't claim to fully understand all the issues, it seems like some of the people on public-appformats are just sending repeated emails saying the same thing, ignoring the counter points that have been made |
| 22:30 | <annevk> | jgraham_, JonF? |
| 22:30 | <jgraham_> | annevk: :) |
| 22:30 | <roc> | obviously reinventing it all makes no sense. but copying just one more feature that you really want is so attractive... |
| 22:31 | <roc> | the rest follows by inductino |
| 22:31 | <annevk> | Maybe we should make it so that where SVG gradients become like <font> tags :) |
| 22:31 | <annevk> | s/where// |
| 22:31 | <jgraham_> | Lachy_: JSON is more widely spoken than YAML but might have a nicer syntax or something |
| 22:31 | <jgraham_> | er s/but/but YAML/ |
| 22:31 | <annevk> | Things you can do through CSS or markup |
| 22:32 | <annevk> | (But SVG gradients are likely far more complex and the CSS stuff is probably a subset.) |
| 22:32 | <Philip`> | JSON syntax is nasty - you'd need to escape all the quotes in your strings, which is pain when you're trying to put JS code in there |
| 22:32 | <roc> | annevk: it may be a subset *for now* |
| 22:32 | <roc> | but I have no confidence that line will be held |
| 22:32 | <jgraham_> | Philip`: Yeah, I can't say I particularly like JSON |
| 22:32 | <Philip`> | SVGT1.2 gradients didn't look very complex when I last looked |
| 22:33 | <Philip`> | though they're probably so limited you'd actually want the SVG1.1 features instead, so I guess that gets more complex again |
| 22:33 | <Philip`> | (like I think SVGT1.2 radial gradients can only have the focus point in the centre) |
| 22:34 | <annevk> | roc, in that case, <font> :) |
| 22:35 | <annevk> | every time I see KML I think it says KLM |
| 22:36 | <roc> | CSS animation and transitions make some sense because SMIL is horrible, and CSS transforms make some sense because wrapping SVG around elements destroys layout, but it seems to me that SVG paint servers could be integrated with CSS without much pain |
| 22:36 | <Philip`> | KLM = Royal Dutch Airlines? |
| 22:37 | <annevk> | Koninklijke Luchtvaart Maatschappij |
| 22:37 | <annevk> | (but yes, that's the English translation) |
| 22:37 | Philip` | has never heard of them, so he never makes that mistake when reading KML :-) |
| 22:39 | <Hixie> | certainly imho anything that css does with gradients should basically re-use the svg paint server system |
| 22:39 | <shepazu> | I don't think that allowing a proper subset of SVG gradients to be expressed in CSS is bad at all |
| 22:39 | <Hixie> | though it might involve new syntax to do so (much like how svg in text/html is new syntax but creates the same dom in the backend) |
| 22:39 | <shepazu> | I think there's room for both "paint servers" |
| 22:40 | <roc> | that leads to disaster |
| 22:41 | <roc> | well, "here is some CSS syntax for SVG" isn't so bad. "Here is some CSS that is supposed to be equivalent to some SVG, but we specify it ourselves anyway" is really bad |
| 22:42 | <Philip`> | It'd be like <canvas> |
| 22:42 | <roc> | my impression was that Webkit's implementation of CSS gradients does not use their SVG code, although I could be mistaken, which disturbs me |
| 22:43 | <annevk> | I hope it doesn't call into Mac OS platform APIs... |
| 22:43 | <Philip`> | annevk: What else would it do? |
| 22:44 | <annevk> | (I'm also in the camp that would like CSS syntax to map to an SVG paint server.) |
| 22:45 | <Philip`> | If I understand correctly (based on approximately no knowledge), WebKit has (or is aiming for?) an internal gradient-painting API, which can be used by SVG/CSS/canvas, which has lots of platform-specific implementations (CG, Cairo, etc) |
| 22:45 | <roc> | *that*'s not a problem |
| 22:46 | <roc> | we have one too, called cairo |
| 22:46 | <Philip`> | so at some level it uses the platform APIs, rather than reimplementing all the drawing code itself |
| 22:48 | <alp> | there's no re-implementing of anything except gradient stop parsing, http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/graphics/Gradient.cpp <- the cross-platform part |
| 22:49 | <alp> | http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/graphics/cairo/GradientCairo.cpp <- the cairo backend for it (needs a tiny bit more work) |
| 22:57 | <roc> | that code doesn't seem to handle the SVG spread modes |
| 22:59 | <othermaciej> | the intent is to use the same core code, if you want the details of how it is at the moment you'd have to ask hyatt |
| 22:59 | <alp> | roc: might be an idea to propose sharing the SVG gradient implementation, or better, providing a patch |
| 23:02 | <roc> | yeah, that would be fun :-) |
| 23:03 | <roc> | but seriously, platform/graphics/Gradient.cpp and svg/graphics/cairo/SVGPaintServerGradientCairo.cpp are clearly duplicating code, so I'm not sure what your comment "there's no reimplementation of anything" is supposed to mean |
| 23:04 | <othermaciej> | roc: hyatt says css gradients share the back end with canvas but not with svg |
| 23:05 | <alp> | roc: Philip` was asking if webkit was re-implementing rasterisation code or using platform APIs. it is the latter |
| 23:07 | <roc> | ok |
| 23:07 | <dhyatt> | roc: othermaciej said you had questions about the gradient stuff |
| 23:07 | <roc> | hello! |
| 23:08 | <roc> | I'm afraid of a gradual import of all of SVG paint servers into CSS and would rather see a general reuse of SVG paint servers |
| 23:08 | <roc> | possibly with some CSS syntax |
| 23:09 | <dhyatt> | how would you link to svg though |
| 23:09 | <roc> | but since you're not reusing your SVG code that way, divergence seems inevitable, which worries me |
| 23:09 | <dhyatt> | i plan to unify all of our gradient code |
| 23:09 | <dhyatt> | canvas and the new css feature use the same back end gradient* object |
| 23:09 | <dhyatt> | i'm going to try to unify svg with it |
| 23:10 | <roc> | good |
| 23:10 | <andersca_> | the grand unification theory |
| 23:11 | <dhyatt> | canvas is sharing with this |
| 23:12 | <roc> | I haven't got a concrete proposal, I'm afraid, but you could allow "fill: url(foo.svg#elem)" on arbitrary elements, perhaps |
| 23:12 | Philip` | guesses specs will need to be careful to give consistent definitions, if the implementations are going to be shared |
| 23:12 | <roc> | that's the problem |
| 23:12 | <roc> | the only safe thing to do is to incorporate by reference |
| 23:12 | <Philip`> | (Opera complained about the canvas gradient spec being nasty, and it'd be better to follow SVG more closely) |
| 23:14 | <roc> | or we could deal with CSS syntax for gradients, even, as long as the spec says "this is equivalent to the SVG: ..." |
| 23:14 | <dhyatt> | i have no real opinion about which gradient definition to follow |
| 23:14 | <roc> | apart from ensuring common behaviour, it's also important to get common evolution |
| 23:14 | <dhyatt> | i think pointing to an svg gradient from css is ok but kind of defeats the point |
| 23:15 | <dhyatt> | which is to not have to load another file to render a gradient :) |
| 23:15 | <roc> | why? |
| 23:15 | <roc> | data: ! |
| 23:15 | <roc> | or HTML5 <svg> |
| 23:15 | <dhyatt> | that would be super clunky compared to just having a native gradient syntax in css though |
| 23:16 | <roc> | or something new |
| 23:16 | <annevk> | C4X |
| 23:16 | <roc> | well like I said, native gradient syntax in CSS isn't so bad |
| 23:17 | <dhyatt> | i think it's fine to be able to point to an svg gradient |
| 23:17 | <dhyatt> | i just don't think anyone would use it if you could just use straight css :) |
| 23:17 | <dhyatt> | unless it had functionality you couldn't get from the css version |
| 23:18 | <roc> | external SVG references would let you do any paint server, including future SVG extensions |
| 23:19 | <roc> | my main concern is that if the spec says more than "this CSS is equivalent to this SVG" then inevitably the specs will diverge |
| 23:19 | <roc> | either by mistake, or via extensions in one spec or the other |
| 23:20 | <roc> | same bad feeling as when SVG 1.2 started dragging in HTML+CSS text layout, one feature at a time |
| 23:21 | <dhyatt> | i don't really view gradients as the sole province of svg though |
| 23:22 | <dhyatt> | gradients were in use as background images on web sites before svg existed |
| 23:22 | <roc> | it's not about a turf war or who was there first, it's about sharing code, specs and brainprint |
| 23:22 | <shepazu> | I agree with dhyatt here |
| 23:22 | <shepazu> | but I also agree with roc |
| 23:22 | <othermaciej> | just because SVG includes gradients doesn't mean gradients are a "vector graphics" feature |
| 23:22 | <shepazu> | :) |
| 23:22 | <dhyatt> | yeah, i'm not disagreeing with the idea of saying the gradients behave the same as svg |
| 23:23 | <dhyatt> | or that the code should be shared internally |
| 23:23 | <dhyatt> | that all sounds good to me |
| 23:23 | <shepazu> | making it a consistent model for developers is what I would aim for |
| 23:23 | <dhyatt> | but for example, for os x, we might add custom extensions to make all the coreimage generators work |
| 23:24 | <shepazu> | that is, page authors... but to a lesser extent, browser developers as well |
| 23:24 | <dhyatt> | they don't necessarily have svg equivalents |
| 23:24 | <dhyatt> | (nor would this be proposed as a spec or anything) |
| 23:24 | <roc> | fine, but I'm sure you can figure that out |
| 23:25 | <othermaciej> | what other generators does CoreImage have? |
| 23:27 | <dhyatt> | lenticular halos, starbursts, checkerboards, ummm |
| 23:27 | <Philip`> | Ooh, can I cover my web page in lens flares? |
| 23:27 | <dhyatt> | stripes, star shine |
| 23:27 | <dhyatt> | i think that's all of them |
| 23:27 | <othermaciej> | lens flares would be more of a filter effect than a generator |
| 23:27 | <dhyatt> | can do gaussian gradients too |
| 23:31 | <dhyatt> | i would need to do research to understand what is different about svg gradients vs. canvas gradients |
| 23:31 | <dhyatt> | Philip said opera disliked something about canvas gradients |
| 23:33 | <Philip`> | dhyatt: http://lists.w3.org/Archives/Public/public-html/2007Oct/0336.html |
| 23:33 | <dhyatt> | anyway, not interested in starting some kind of svg turf war :) |
| 23:34 | <Philip`> | http://lists.w3.org/Archives/Public/public-html/2007Oct/0350.html says some things about canvas vs SVG definitions |
| 23:35 | <Philip`> | (Only WebKit almost implements canvas radial gradients according to the spec) |
| 23:35 | <Philip`> | (and that's mostly because the spec was written to match WebKit, since the other implementations were too buggy) |
| 23:36 | <dhyatt> | i see. |
| 23:36 | <dhyatt> | so my radial gradient syntax is "canvas-biased" |
| 23:36 | <roc> | "uh oh" |
| 23:37 | <dhyatt> | or more accurately "cg-biased" |
| 23:37 | <dhyatt> | since canvas itself is cg-biased |
| 23:38 | <Philip`> | CG varies a bit at radial gradients between OS X 10.4 and 10.5, which makes it more fun |
| 23:39 | <dhyatt> | i don't really understand the difference rendering-wise |
| 23:39 | <Philip`> | (I suppose that's only in edge cases, but I'm pointlessly interested in edge cases) |
| 23:40 | <dhyatt> | how would you translate the svg way into cg |
| 23:40 | <othermaciej> | dhyatt: I really want gradients for text, but I guess the best way to do that is to allow some general sense of fill rules for text in CSS |
| 23:40 | <dhyatt> | i guess i could just look at our code heh |
| 23:40 | <dhyatt> | othermaciej: yeah, background-clip: text does it, but that's kind of a hack |
| 23:40 | <dhyatt> | othermaciej: fantasai suggested possibly a text-fill |
| 23:41 | <dhyatt> | we already have text-fill-color |
| 23:41 | <dhyatt> | that could become part of a larger shorthand |
| 23:41 | <othermaciej> | yeah, I mean, what if I want to do gradient text on a different gradient background? |
| 23:41 | <othermaciej> | for my Super Swingin' '70s blog |
| 23:41 | <dhyatt> | well because of multiple backgrounds you ca nactually do that |
| 23:41 | <dhyatt> | evne using the background-clip: text hack |
| 23:41 | <othermaciej> | background-clip: text only clips the frontmost background? |
| 23:41 | <dhyatt> | but i don't like the hack since it puts the text rendering at the background level |
| 23:41 | <dhyatt> | so selection looks funny |
| 23:41 | <dhyatt> | and text dragging doesn't draw right |
| 23:42 | <dhyatt> | othermaciej: no you can clip any background in the stack |
| 23:42 | <dhyatt> | so you can create some intriguing effects :) |
| 23:42 | <othermaciej> | oh, background-clip can apply to any background? |
| 23:42 | <othermaciej> | I see |
| 23:42 | <dhyatt> | since one in the middle can clip to text and then a higher background can even overlay it with transparency |
| 23:45 | <dhyatt> | ok dinner |
| 23:46 | <mcarter> | hello |
| 23:47 | <Philip`> | mcarter: Hello |
| 23:48 | Philip` | sees http://benjamin.smedbergs.us/blog/2008-04-14/hgweb-viewer-canvas-version/ on SVG vs canvas |