| 10:31 | <cyclist> | so basically in, <h1>foo<h2>bar</h2> |
| 10:32 | <cyclist> | the <h2> closes the <h1> |
| 10:32 | <cyclist> | can't say this is clear from the specification |
| 10:35 | <Dashiva> | A start tag whose tag name is one of: "h1", "h2", "h3", "h4", "h5", "h6" |
| 10:35 | <Dashiva> | If the current node is an element whose tag name is one of "h1", "h2", "h3", "h4", "h5", or "h6", then this is a parse error; pop the current node off the stack of open elements. |
| 10:36 | <Dashiva> | It's not explicitly mentioned in the author parts because it's invalid. You can't put a heading inside another heading |
| 10:36 | <cyclist> | ahh. ok. so <h1><b>foo<h2>bar</h2> |
| 10:37 | <cyclist> | also closes the <h1> although the current node is <b>? |
| 10:39 | <Dashiva> | No |
| 10:39 | <cyclist> | the current node is not <b> or the <h1> isn't closed? |
| 10:40 | <annevk2> | is the current node is <b> |
| 10:40 | <cyclist> | So, anyway, maybe it would be better to say "emit close tag" instead of "parse error" |
| 10:41 | <annevk2> | hmm, you're not reading correctly |
| 10:41 | <cyclist> | yes sorry |
| 10:42 | <annevk2> | "pop the current node off the ..." is the bit where the element is "closed" |
| 10:42 | <annevk2> | "parse error" is just an indication to validator implementors that they need to show an error if that condition is hit |
| 10:43 | <cyclist> | ok. thanx |
| 10:43 | <annevk2> | if reading gets too boring, you can always toy around with http://livedom.validator.nu/ |
| 10:43 | <annevk2> | it should be pretty close to perfect |
| 10:45 | <cyclist> | yes, but a fact is that a vast part of the web cannot be forced to fix their pages |
| 10:45 | <cyclist> | (because mozilla and IE accepted weird sh*t that confuses bots) |
| 10:45 | <Dashiva> | They don't have to fix them |
| 10:46 | <cyclist> | so , as a web browser author, i have to support all weird crap |
| 10:46 | <Dashiva> | That's what the spec is for, yes |
| 10:46 | <cyclist> | "will be for" when complete :) |
| 10:46 | <cyclist> | hope this happens soon |
| 10:47 | <gsnedders> | The parsing section has been basically done for ages |
| 10:47 | <annevk2> | I don't quite understand why you give me a reply like that... |
| 10:47 | <Dashiva> | gsnedders: Yeah, if you enjoy infinite loops :P |
| 10:47 | <gsnedders> | Really what needs to happen with the parsing section is to get impl. experience of it to see how it works on a large scale of websites |
| 10:48 | <gsnedders> | Dashiva: Hey, that was only innerHTML :P |
| 10:50 | gsnedders | heads off to buy bread and other basic food stuff so he can live to fight another day |
| 10:51 | <cyclist> | The thing is that if there is an error in a page, mozilla wouldn't bail out. It will always try to do something "intelligent" |
| 10:51 | <cyclist> | So documenting all those undefined intelligences is a bit impossible |
| 10:52 | <Dashiva> | <insert hixie's sig here> |
| 10:52 | <gsnedders> | cyclist: Why is it impossible? |
| 10:52 | <cyclist> | So, i'm saying that there may always be pages in the www for which mozilla does something that isn't in the spec |
| 10:52 | <gsnedders> | cyclist: If it can be implemented, it can be spec'd. |
| 10:53 | <gsnedders> | The spec defines parsing for _any_ character stream. |
| 10:53 | <cyclist> | by reverse engineering mozilla, yes. |
| 10:53 | <annevk2> | cyclist, dude, that's what the spec does... |
| 10:54 | <gsnedders> | If there are pages that break with the spec algorithm but not with existing web browser, there is a bug in the spec. |
| 10:54 | <cyclist> | excellent news! |
| 10:54 | <annevk2> | cyclist, it says "parse error" but then it continues telling you what to do |
| 10:54 | <annevk2> | cyclist, as I said, the "parse error" thing is for validator implementors |
| 10:54 | <gsnedders> | Well, any impl can fail on a parse error. I doubt any will, though. |
| 10:55 | <annevk2> | cyclist, did you even play with the sandbox in the link I provided? |
| 10:55 | <cyclist> | i can't (not capable web browser) |
| 11:00 | <cyclist> | OK, for example: <body><!-- comment > this is visible </body> |
| 11:04 | <cyclist> | And in: <h1><b>foo<h2>bar</h2>xxx |
| 11:04 | <cyclist> | the <h2> closes the <h1> but not the <b> |
| 11:26 | <annevk42> | cyclist, actually, that depends on the impl |
| 11:27 | <cyclist> | that's the official position of the spec? |
| 11:29 | annevk42 | shrugs |
| 11:39 | <Dashiva> | cyclist: No, the spec has a single behavior. But some browsers don't use the same algorithm yet. |
| 11:42 | <cyclist> | so the goal is that the browsers will implement the spec, or that the spec will reverse engineer mozilla? |
| 11:43 | <Dashiva> | The spec primarily describes cross-browser compatible behavior |
| 11:45 | <Dashiva> | If browsers disagree, the spec usually picks the IE behavior (if it is sane) or the most sane behavior available. |
| 11:47 | <cyclist> | so, when annevk2 before said "that depends on the impl", it means: not standarized yet |
| 11:52 | <cyclist> | and thus, is a bug report? |
| 11:53 | <Dashiva> | Well, e.g. firefox has an alternate parser under development |
| 11:54 | <Dashiva> | http://blog.whatwg.org/test-html5-parsing |
| 11:54 | <cyclist> | but if it makes part of the web un-renderable, it will default to the other parser |
| 11:54 | <Dashiva> | No |
| 11:55 | <Dashiva> | Then the spec gets changed to support that part of the web |
| 11:55 | <cyclist> | ok |
| 12:00 | <Dashiva> | http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#the-before-head-insertion-mode |
| 12:00 | <Dashiva> | I don't see how the note about ending up in 'after head' is correct |
| 12:00 | <Dashiva> | If a head start tag is seen, you get put into 'in head', and it doesn't say anything about seeing a head end tag |
| 12:02 | <Dashiva> | If the note is correct, <!DOCTYPE html><title>Title</title><p></p> would give a parse error because title was outside head |
| 12:03 | <olliej_> | Dashiva: you would get a validation error -- the browser is unlikely to care too much and you will probably hit one of the error handling paths |
| 12:03 | <olliej_> | Dashiva: which i think are also defined |
| 12:03 | <olliej_> | Dashiva: but this isn't an area i'm intimately familiar with |
| 12:03 | <olliej_> | so i don't know the technical specifics of what would end up happening |
| 12:04 | <Dashiva> | It validates fine in the validator, though. Another reason I think the note is suspect. |
| 12:04 | <olliej_> | the validator is still in development |
| 12:05 | <olliej_> | so it's possibly a validator error not spec error -- the validator is ostensibly based on the spec |
| 12:05 | <gsnedders> | It should validate, taht |
| 12:05 | <gsnedders> | Anyhow, lunch time for me |
| 12:05 | <Dashiva> | olliej_: The note is informative, not normative. |
| 12:06 | <Dashiva> | I'm saying it conflicts with the normative spec text |
| 12:14 | <gsnedders> | Dashiva: Yeah, that note is bogus |
| 12:16 | <gsnedders> | base, command, link, meta, title, noscript, noframes, style, script will only move to in head |
| 12:34 | <gsnedders> | Wow. I'm surprised there weren't two hundred replies to feedback from MS. |
| 12:35 | <gsnedders> | Dashiva: I take it you won't kill me if I send email about it? |
| 12:35 | <Dashiva> | My name is already in the spec, so no harm done if you do :) |
| 12:43 | annevk2 | wonders what the harm would be if it wasn't |
| 12:43 | <gsnedders> | annevk2: Hurting Dashiva's vanity. |
| 12:52 | gsnedders | stops looking at the parser |
| 13:39 | <Dashiva> | gsnedders: Does it make your head hurt? |
| 18:24 | <tantek> | greetings, for those of you that edit/contribute to the WHATWG wiki, I want to encourage you to place your contributions in the public domain by adding {{cc-public-domain-release}} to your User page. I done so myself: http://wiki.whatwg.org/wiki/User:Tantek |
| 19:51 | <hober> | done. |
| 21:05 | jgraham_ | reads the microsoft feedback |
| 21:05 | <jgraham_> | Not really worth waiting two years for |
| 21:05 | gsnedders | guesses he'll get around to reading it tomorrow |
| 21:06 | <hober> | jgraham_: indeed, it's pretty underwhelming |
| 21:07 | gsnedders | also notes it isn't, contrary to popular belief, the first feedback they've sent |
| 21:07 | <jgraham_> | But at least they identified a guenuine area that he spec could improve accessibiliy (make it clearer that <nav> should be treated specially by AT) that everyone else missed because it wasn't already in HTML4 |
| 21:07 | <jgraham_> | gsnedders: It is the first feedback that suggests a systematic review of the whole drat rather than just of specific sections |
| 21:08 | <jgraham_> | *draft |
| 21:12 | jgraham_ | kind of wishes that hsivonen hadn't brought up "where did @summary come from" because it just reenforces the regressive approach to accessibility that has characterised much of the discussion in the HTML WG |
| 21:12 | <jgraham_> | Although there has been a litle progress recently |
| 21:15 | <Hixie> | i don't fully understand what manu's draft is supposed to be |
| 21:15 | <Hixie> | i mean, i understand his real motivation (the warning in the microdata section saying that rdfa is an alternative) |
| 21:15 | <Hixie> | but what is the "warning" draft supposed to be? A comprehensive list of controversial topics in the spec? |
| 21:16 | <Dashiva> | A TODO list for LC :) |
| 21:17 | <jgraham_> | I assume wihout evidence it is a list of sections that he personally disgrees with phrased in a way that makes it sound like others agree with his disagreement |
| 21:18 | <Hixie> | maybe i should make one of those |
| 21:19 | <Hixie> | gsnedders: you here? |
| 21:19 | <gsnedders> | Hixie: yes |
| 21:19 | <Hixie> | gsnedders: so, i'm thinking of doing references |
| 21:19 | gsnedders | doesn't like the sound of this |
| 21:19 | <gsnedders> | This sounds like Hixie wanting me to do more stuff for him. |
| 21:19 | <jgraham_> | I thought the idea was that we all make one of those, it finally transpires that everything doesn't enjoy consensus according to at least one person and the whole effort collapses in a festering heap of politics |
| 21:20 | <jgraham_> | But I might just be particularly cynical right now :) |
| 21:20 | <Hixie> | gsnedders: could i convince you to make a patch to anolis that removes elements with IDs that are marked with a particular class if there are no <a href=""> elements in the document that point to that ID? |
| 21:20 | jgraham_ | should do something useful like update his anolis |
| 21:20 | <Hixie> | jgraham_: well, if that happens, i guess the whatwg takes over again :-) |
| 21:21 | <gsnedders> | Hixie: Recursively, or just the element itself? |
| 21:21 | <Hixie> | gsnedders: the element and any children |
| 21:21 | gsnedders | guesses just the element itself |
| 21:21 | <gsnedders> | Oh, OK |
| 21:21 | <gsnedders> | jgraham_: You assume I've updated anolis :P |
| 21:21 | <Hixie> | oh and the following element, i guess, since i haven't alloweded <di> yet |
| 21:22 | <Hixie> | gsnedders: basically, i have <a href="#refsXXX">[XXX]</a>s around, and I have <dt id="XXX"></dt><dd></dd>s, and I'd like the <dt><dd> pairs to go away if none of the href="#refs" refer to them |
| 21:22 | <jgraham_> | gsnedders: added 5 changesets with 13 changes to 9 files |
| 21:22 | <Hixie> | gsnedders: that way i can have just one source references section for all the specs, and it gets automatically trimmed for each spec |
| 21:23 | <Lachy> | Hixie, what's wrong with using the references system that we already have? |
| 21:23 | <Hixie> | gsnedders: it seem slike a relatively simple thing to do, i mean, i could do it in JS easily enough |
| 21:23 | <Hixie> | Lachy: what's that? |
| 21:23 | <gsnedders> | Lachy: The one I haven't merged into anolis yet? |
| 21:23 | <Lachy> | the one that gsnedders already wrote, which works similarly to the one in the CSS spec gen |
| 21:23 | <Hixie> | Lachy: does it allow me to micromanage the HTML for each reference? |
| 21:24 | <Lachy> | why do you need to micromanage like that? |
| 21:24 | <gsnedders> | Because he's an asshole :P |
| 21:24 | <Hixie> | because otherwise the markup isn't what i want |
| 21:24 | <Hixie> | that's the reason i stopped using the csswg one |
| 21:25 | <Hixie> | i had to write the references in some other format, and then pray it turned out right |
| 21:25 | <Hixie> | instead of just writing the references in the first place |
| 21:25 | <Lachy> | isn't that just a matter of setting up the template the way you want it, but still have them generated in the same way? |
| 21:25 | <Hixie> | not as far as I can tell |
| 21:25 | <Hixie> | anyway it's just easier to deal with markup than yet another format |
| 21:28 | <Hixie> | gsnedders: anyway, would that be something you think you could do relatively soon? It's fine if not, I can write it myself too, I just don't want us to duplicate efforts :-) |
| 21:28 | <Hixie> | woah, anolis changed |
| 21:29 | <Lachy> | ok, so you want the functionality of the references generator, but instead of using the existing data file (I can't remember what that format is called), you want it to use an HTML based format |
| 21:29 | gsnedders | looks left |
| 21:29 | gsnedders | looks right |
| 21:29 | <gsnedders> | Changed? |
| 21:29 | Lachy | wonders if gsnedders is crossing the street |
| 21:29 | Hixie | finds his two-line patch in the source turns into a 50,000 line patch in index because of jgraham_'s update :-) |
| 21:29 | <Philip`> | He forgot to look left again :-( |
| 21:30 | jgraham_ | blames gsnedders |
| 21:30 | gsnedders | blames jgraham_ |
| 21:30 | <Hixie> | Lachy: i don't want anything external, really |
| 21:30 | <Hixie> | Lachy: i'm happy with writing all the references myself |
| 21:31 | <gsnedders> | Hixie: What has changed? |
| 21:31 | <Lachy> | ok |
| 21:31 | <Hixie> | gsnedders: jgraham updated pms |
| 21:31 | <gsnedders> | Hixie: Yes, but what did it change? |
| 21:31 | <gsnedders> | :P |
| 21:31 | <Hixie> | Lachy: my only problem is i don't want to have to figure out which spec generated from my one source doc references each reference |
| 21:31 | <Hixie> | gsnedders: have a look at the diff |
| 21:32 | <gsnedders> | What diff? Where? |
| 21:33 | gsnedders | sees no commit for three hours |
| 21:33 | <Hixie> | oh the diff was bigger than the maximum size of e-mails to commit-watchers |
| 21:34 | <Hixie> | hah |
| 21:35 | <Hixie> | svn diff -r 3569:3570 http://svn.whatwg.org/webapps/index |
| 21:35 | <gsnedders> | Not at http://html5.org/tools/web-apps-tracker either |
| 21:35 | <Hixie> | it's the "typo" checkin on tracker |
| 21:36 | <gsnedders> | That's a small diff |
| 21:36 | <gsnedders> | :P |
| 21:36 | <gsnedders> | Is it all whitespace changes? |
| 21:37 | <Hixie> | entities changed too |
| 21:37 | <gsnedders> | That's html5lib issue, then, no? |
| 21:39 | <gsnedders> | It's not US-ASCII any more |
| 21:41 | <gsnedders> | hmm |
| 21:41 | <gsnedders> | jgraham: Did you update html5lib too? |
| 21:44 | <gsnedders> | Did anyone recieve emails on public-html from me today? |
| 21:47 | <jgraham> | gsnedders: No |
| 21:47 | <gsnedders> | Just Anolis to tip? |
| 21:47 | <jgraham> | gsnedders: Yes |
| 21:48 | <gsnedders> | huh. |
| 21:48 | <gsnedders> | I haven't changed anything relating to output stuff. |
| 21:59 | <Hixie> | http://www.erc.gov.ph/new/m-aboutus.htm (look at the bottom) |
| 22:00 | <gsnedders> | hah |
| 22:03 | <Hixie> | IBM used to do that too http://www-03.ibm.com/ibm/history/exhibits/music/music_clips.html |
| 22:06 | <annevk2> | some African telco has a great rap song |
| 22:20 | <Hixie> | annevk2: marketing? or internal? |
| 22:21 | <annevk2> | I can't find the link :/ |
| 22:23 | <annevk2> | If I remember I'll ask some people at work about it |
| 22:26 | <Hixie> | gah i hate this conforming-with-warning crap |
| 22:26 | <Hixie> | i want to go back to non-conforming but downplayed |
| 22:28 | <othermaciej> | I'm not sure conforming-with-warning is very good, but "downplayed error" never made sense to me |
| 22:29 | <Hixie> | it's just errors that we don't make a fuss about |
| 22:29 | <Hixie> | like using language="Javascript" on <script> |
| 22:29 | <Hixie> | it's mostly harmless |
| 22:30 | <Dashiva> | Dr Hickson. Again we see there is nothing you can spec that we cannot take away. |
| 22:30 | <othermaciej> | As I see it, people will either try to get down to 0 conformance errors, or not care much |
| 22:30 | <othermaciej> | I doubt anyone will try to fix all other errors but be happy to leave the "downplayed" ones |
| 22:31 | <othermaciej> | so I don't think it achieves anything |
| 22:31 | <Dashiva> | I think in the end it doesn't really matter whether the validator gives a "warning" or a "downplayed error" or whatever we call it, as long as the message is there |
| 22:31 | <othermaciej> | if something is harmless, it shouldn't be an error because it will waste people's time to deal with it, if they have a goal of getting to 0 errors |
| 22:31 | <othermaciej> | so they can have the "conforming" badge that hsivonen doesn't want to give them |
| 22:32 | <othermaciej> | if we expect people to pick and choose errors to fix, then that's like admitting conformance is meaningless |
| 22:33 | <Hixie> | othermaciej: there are errors that are only important in new documents, but that don't matter much if you're just updating an old doc |
| 22:33 | <Hixie> | othermaciej: those were the downplayed ones |
| 22:33 | <Hixie> | othermaciej: i'm open to other solutions |
| 22:33 | <webben_> | that is basically transitional. |
| 22:33 | <Hixie> | othermaciej: i don't like this conforming-with-warning crap for the same reason -- i think people will treat warnings as errors too |
| 22:33 | <Hixie> | webben_: yeah, though clearly that approach failed. |
| 22:33 | <othermaciej> | people can get the magical "conforming" badge without fixing all the errors |
| 22:34 | <othermaciej> | but even if that's the case, the problem is that "warning" is too strong, rather than too weak |
| 22:35 | <webben_> | How about "Tip"? |
| 22:35 | <webben_> | "Tip: Consider using caption with details instead of summary..." or whatever |
| 22:35 | <othermaciej> | my bottom line is this: if a particular construct is not harmful and not likely to indicate an authoring mistake, then it seems silly to call it a conformance error |
| 22:36 | <Hixie> | othermaciej: they are authoring mistakes, in that it is a waste of the author's time to be adding these features to new documents |
| 22:36 | <Hixie> | othermaciej: so we do want to make them non-conforming in new documents |
| 22:36 | <othermaciej> | well it's also a waste of the author's time to write a / at the end of their <br> tags |
| 22:36 | <Hixie> | webben_: summary is an aberration in this discussion, in that it doesn't have the same reason for being in this category as the other things do |
| 22:36 | <othermaciej> | or to include an xmlns declaration in a text/html document |
| 22:36 | <othermaciej> | or to quote attributes that don't need to be quoted |
| 22:36 | <Hixie> | othermaciej: yeah, but you need to allow those to enable polyglot documents, which some people want |
| 22:36 | <webben_> | Hixie: Well, the same could apply to language="JavaScript" |
| 22:37 | <jgraham> | In the specific case of @summary I regard it as a mistake to use the hidden-data solution when various superior alternatives are avaliable |
| 22:37 | <webben_> | Hixie: "Tip: You don't need to specify scripts are JavaScript!" etc. |
| 22:37 | <Hixie> | othermaciej: and in some cases, quoting attributes is preferable |
| 22:37 | <othermaciej> | jgraham: summary is in a different category |
| 22:37 | <Hixie> | webben_: the language="" attribute is non-conforming except when it's redundant with type="" |
| 22:37 | <jgraham> | othermaciej: True enough |
| 22:38 | <othermaciej> | Hixie: I think "it's a waste of time" is a different category of problem than "this is harmful" or "if your document is like this, you probably did something wrong" |
| 22:38 | <Hixie> | webben_: the problem is with the language="" attribute, not that it is js |
| 22:38 | jgraham | will go to sleep rather than get involved with this :) |
| 22:38 | <othermaciej> | Hixie: because if you do it, and then get the error, and then need to remove it, even more of your time is wasted |
| 22:38 | <Hixie> | othermaciej: *shrug* |
| 22:38 | <webben_> | Hixie: Fine, but my point was more about how to cast the messaging than what the message is. |
| 22:38 | <Hixie> | webben_: well, that's up to the validator authors, i don't care what words they use exactly |
| 22:39 | <webben_> | I think offering authors tips might be more likely to educate them in the long run. |
| 22:39 | <webben_> | since I think authors distrust validators that warn them about things they don't care about |
| 22:39 | <Hixie> | i don't think tips really address the issue of wanting to be firm with authors of new pages and lax with authors of existing pages being updated |
| 22:40 | <webben_> | Hmm. I kind thought it did - tips are something you want authors to consider going forward, by you can ignore it if you're just validating your old stuff as HTML5. |
| 22:40 | <othermaciej> | "be firm" seems like the wrong framing to me, when the issue is practices that are useless but also harmless |
| 22:40 | <Lachy> | Hixie, wasn't the only reason you changed from downplayed error to conforming but obsolete to deal with summary in a less objectional way, despite not actually having that effect? |
| 22:41 | <Hixie> | Lachy: yes |
| 22:41 | <Lachy> | so now that summary is effectively fully conforming, why can't we revert the other things to downplayed errors? |
| 22:41 | <othermaciej> | I think the old "downplayed errors" being errors was also foolish, but I never specifically asked Hixie to change them, and I don't think anyone was willing to lie down across the railroad tracks over it |
| 22:42 | <Lachy> | I don't like downplayed errors much either, and would rather have them simpliy be non-conforming, but I prefer downplayed errors to the current crap in the spec |
| 22:42 | <Hixie> | webben_: well, that's the idea, but i think in practice authors will treat whatever the UA says as an error, and either aim for zero "tips", "warnings", "errors", whatever, regardless of whether it's a new doc or not, or ignore the tips for all classes of documents |
| 22:42 | <Hixie> | Lachy: summary still triggers the warning |
| 22:43 | <othermaciej> | I would frame the issue like this: withholding conformance is a "punishment", a "punishment" should be for something you did "wrong", for something useless but harmless, the right response is not "punishment" but "advice" |
| 22:43 | <Lachy> | so? Just make it a one-off exception dealt with in its own special way like it already is anyway, and make the rest non-conforming. |
| 22:43 | <webben_> | Hixie: I think if the UI doesn't clearly distinguish between errors and other things such that it destroys trust in error reporting, that's a big problem with the UI. |
| 22:44 | <Hixie> | webben_: maybe |
| 22:44 | <webben_> | if it's impossible to create a UI that can't make that distinction clear, best to only report clear errors. |
| 22:44 | <webben_> | *that can make |
| 22:44 | <webben_> | (I think) |
| 22:44 | <othermaciej> | I think validator.nu makes errors pretty clearly distinct from other kinds of messages |
| 22:44 | <othermaciej> | also makes it clear when you get to 0 errors |
| 22:45 | <webben_> | I don't think authors would confuse Tips with Errors. |
| 22:45 | <webben_> | (well unless you present them in red with warning symbols) |
| 22:46 | <Hixie> | fair enough |
| 22:47 | <othermaciej> | "Tips" would be harder to mistake for something you absolutely need to fix than "Warnings" |
| 22:47 | <gsnedders> | pink! |
| 22:47 | <gsnedders> | Everyone likes nice, pink, cuddly, Hello Kitty signs! |
| 22:47 | <webben_> | lulz :) |
| 22:48 | <gsnedders> | Sorry, I thought the discusion in here was getting far too serious. |
| 22:48 | <webben_> | I agree the current W3C validators have a definite Hello Kitty deficit. ;) |
| 22:49 | <othermaciej> | clearly instead or "Warning" or "Error" it should be a "Hello Kitty Happy Fun Time Indicator" |
| 22:51 | <jcranmer> | Hello Kitty is a printer at my school |
| 22:51 | <jcranmer> | so a "Hello Kitty Happy Fun Time Indicator" means "nothing's printing so the print queue now consists of at least 30 entries" |
| 23:35 | <Hixie> | pimpmyspec.net seems to have stopped working |
| 23:36 | <tantek> | that's a hilarious domain |
| 23:37 | <Hixie> | oh, no, it works again |
| 23:43 | <csarven> | Which element would best present the allowed number of characters remaining for an input field? |
| 23:43 | <csarven> | s/present/represent |
| 23:43 | <Hixie> | no element |
| 23:43 | <Hixie> | just text |
| 23:43 | <Hixie> | possibly <small> if this is supposed to just be a minor piece of text |
| 23:43 | <csarven> | I'm thinking samp |
| 23:44 | <csarven> | It is minor indeed |
| 23:44 | <Hixie> | <samp> is for sample computer output, so it would be highly inappropriate unless you were writing an example of what it might look like |
| 23:45 | <csarven> | <E>140</E> would indicate that the textarea allows 140 chars |
| 23:45 | <Hixie> | what's wrong with just 140 |
| 23:45 | <Hixie> | with no element |
| 23:45 | <csarven> | It would be updated dynamically with script |
| 23:45 | <Hixie> | then use <span> |
| 23:46 | <csarven> | Need to be able to target that for styling and updating the value |
| 23:46 | <Hixie> | from what you've said, i'd use either <small> or <span> |
| 23:47 | <csarven> | Alright, span it is :) |
| 23:47 | <csarven> | Thanks |
| 23:47 | <ttepasse> | If it were usable, I'd think about <output>. |
| 23:48 | <Hixie> | <output> is more for the result of calculations, but one could argue that it is the right element here, yeah |
| 23:49 | <Hixie> | actually yeah, <output> might be the best answer |
| 23:49 | <csarven> | Didn't know <output> existed |
| 23:49 | webben_ | wonders about maxlength + CSS generated content. |
| 23:49 | <Hixie> | it's not widely implemented yet |
| 23:49 | <csarven> | webben_ maxlength is more of a guideline in my case |
| 23:50 | webben_ | would probably use span though ... possibly floated/positioned right out of a label |
| 23:50 | <csarven> | You could technically send more than 140 chars (the text may need to be processed e.g., shortURLing) |
| 23:50 | <webben_> | I see. |
| 23:52 | <csarven> | I think I could totally remove that <E>140</E> from the original HTML output and show it with JavaScript |
| 23:52 | <csarven> | I'm not sure if I can use <output> actually. We are using XMLWriter |