| 00:08 | <GPHemsley> | Hixie: Any plans to make CSS4 at some point that actually makes things easy to position? |
| 00:49 | <takkaria> | you should look at CSS3's layout module, it uses ASCII art for that |
| 00:49 | <takkaria> | http://www.w3.org/TR/css3-layout/ |
| 01:12 | <GPHemsley> | takkaria: Hah. I figured there was some CSS3 thing "in the works". |
| 03:24 | <Simetrical> | Hixie, aww. Are you not going to tell him? I've been staying up late to see the end of this. |
| 03:25 | <Simetrical> | You're insanely more diplomatic than me, though, props for that. :P |
| 03:31 | <GPHemsley> | ? |
| 03:32 | <othermaciej> | tell who what? |
| 03:32 | <TabAtkins> | I am also confused, Simetrical. |
| 03:32 | <Simetrical> | Some guy in #chromium was arguing with Hixie about HTML 5. More or less telling him he didn't know what he was talking about. |
| 03:33 | <othermaciej> | oh |
| 03:33 | <othermaciej> | does #chromium have logs? |
| 03:33 | <Simetrical> | He apparently had no idea who Hixie is. I was waiting for a line like "<markybob> Hixie, you don't know anything about HTML 5" so I could put it on my page of quotes, but he's fallen silent now. |
| 03:34 | <Simetrical> | http://echelog.matzon.dk/logs/browse/chromium/1251064800 Scroll back to 2:51:48 for the start of the discussion. |
| 03:34 | <othermaciej> | lols |
| 03:35 | Simetrical | has been wondering lately if he should change his IRC nick to AryehGregor so people can more easily match him up with his mailing list posts |
| 03:37 | <othermaciej> | fwiw I did not realize you were the same person until you just said so |
| 03:37 | <Simetrical> | Yeah, that's what I figured. |
| 03:37 | <Simetrical> | I send mail as "Aryeh Gregor <Simetrical+xxx⊙gc>" these days, but people usually don't look at the address. |
| 03:40 | <TabAtkins> | That... that log is glorious. |
| 03:40 | <Simetrical> | No great soundbites, though. :( |
| 03:41 | <TabAtkins> | Simetrical: I suggest changing it. I recognize it only because when you switched your email address name over mid-conversation in www-style I noticed. |
| 03:42 | <Simetrical> | I used to always use Simetrical everywhere, but a while back I switched to my real name for things that I'd want a potential employer to find when searching for my name. Since the top Google hit for me was my grandfather's New York Times obituary. :) |
| 03:42 | <Simetrical> | Since I use freenode pretty much only for programming- and math-related stuff, it would make sense. |
| 03:42 | <TabAtkins> | I sorta wanna tell markybob he was talking to Hixie. |
| 03:44 | <TabAtkins> | But I wouldn't want to deprive you of the pleasure, AryehGregor. |
| 03:44 | <TabAtkins> | Since Hixie doesn't seem to want to do it himself. ^_^ |
| 03:44 | <AryehGregor> | Hmm, maybe I should use just Aryeh instead, or aryeh. It's a pretty distinctive name, after all. |
| 03:45 | <aryeh> | Oh, that's registered. |
| 03:45 | <aryeh> | Rats. |
| 03:46 | <othermaciej> | that's how I ended up "othermaciej" |
| 03:46 | <othermaciej> | all the good choices wer etaken |
| 03:46 | <TabAtkins> | I should probably register my nick |
| 03:47 | <AryehGregor> | I guess your name is like mine, distinctive to your average netizen but common enough in absolute terms that someone else has already taken it. |
| 03:47 | <TabAtkins> | Hmm, what's the command for that? |
| 03:47 | <AryehGregor> | /ns help |
| 03:50 | <TabAtkins> | I'll leave #chromium up and check in in a little while, AryehGregor, to see what's happened. ^_^ |
| 04:09 | <AryehGregor> | Oh, well, looks like he's not responding. I'll go to bed now, then. |
| 06:46 | <GPHemsley> | Well, that was entertaining... about two hours later.... ^_^ |
| 06:47 | <othermaciej> | eh? |
| 06:49 | <foolip> | hehe, funny |
| 06:58 | <GPHemsley> | othermaciej: The #chromium debate |
| 07:01 | <othermaciej> | I give Hixie props for not arguing from authority |
| 07:01 | <othermaciej> | even though he would have been totally justified |
| 07:04 | <Dashiva> | Are there cliff notes? |
| 09:16 | <Hixie> | http://skillsmatter.com/course/ajax-ria/enterprise-comet-ajax |
| 09:16 | <Hixie> | there are (expensive) courses in this stuff already?! o_O |
| 09:26 | <othermaciej> | Hixie: wow, I picked the wrong way to incorporate HTML5 into my career |
| 09:26 | <othermaciej> | clearly, implementing it is for losers |
| 09:40 | <Hixie> | jgraham: what do i add to the url string to do this annotation stuff? |
| 09:43 | <jgraham> | Hixie: http://krijnhoetmer.nl/irc-logs/html-wg/20090823#l-101 |
| 09:43 | <Hixie> | thx |
| 09:44 | <Hixie> | that contains the issue tracker data too? |
| 09:46 | <jgraham> | Hixie: The long url is the url for the service that gives annotations + issue data -> extended annotations format file |
| 09:47 | <Hixie> | what should i search for in its output to see an example of a tracker annotation? |
| 09:47 | <jgraham> | ISSUE- |
| 09:47 | <jgraham> | Wait |
| 09:47 | <jgraham> | Which output? |
| 09:47 | <jgraham> | The XML file or the spec? |
| 09:47 | jgraham | feels he is not being very clear |
| 09:47 | <Hixie> | XML file |
| 09:48 | <jgraham> | In the xml file the issues are <issue> elements |
| 09:48 | <Hixie> | i find none |
| 09:48 | <Hixie> | in http://pimpmyspec.net/aquarium.py/annotations/output?spec_status=WD&annotations_url=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fstatus.cgi%3Faction%3Dget-all-annotations&tracker_url=http%3A%2F%2Fwww.w3.org%2Fhtml%2Fwg%2Ftracker%2F |
| 09:48 | <jgraham> | Oh well something is broken then |
| 09:48 | <jgraham> | This worked for me yesterday... |
| 09:50 | <jgraham> | Yeah I must have broken something :( |
| 09:51 | <Hixie> | could you set the class of the elements you output to "XXX annotation" or some such? |
| 09:51 | <Hixie> | so i can style it separately? |
| 09:51 | <jgraham> | Hixie: Sure |
| 09:51 | <jgraham> | (I just wanted some style so I picked an existing classname) |
| 09:51 | <Hixie> | is it always just one <p>? |
| 09:51 | <jgraham> | iirc yes |
| 09:52 | <Hixie> | only after an <hx>? or wherever a matching ID is found? |
| 09:52 | <Hixie> | found the answer! |
| 09:52 | <Hixie> | "<p><dfn id="the-body-element">The body element</dfn><p class="XXX"><b>Status: </b>" |
| 09:52 | <Hixie> | that's not gonna work |
| 09:53 | <jgraham> | Yeah, it just looks for an ID |
| 09:54 | <jgraham> | Although I thought we only had annotations after headings |
| 09:54 | <Hixie> | we have annotations all over the place |
| 09:54 | <Hixie> | annotations just need an ID |
| 09:55 | <jgraham> | Interesting |
| 09:58 | <virtuelv> | holy mother of god |
| 09:59 | <virtuelv> | (Yes, I'm looking at skillsmatter) |
| 10:16 | <Hixie> | i meant to post this here: http://www.whatwg.org/specs/web-apps/current-work/temp |
| 10:16 | <Hixie> | instead i twittered it |
| 10:16 | <Hixie> | but we won't worry about that! |
| 10:23 | <jgraham> | Hixie: The problems with the issue annotation thing may or may not be fixed |
| 10:23 | <Dashiva> | How unexpected |
| 10:24 | <jgraham> | Dashiva: ? |
| 10:26 | <Hixie> | jgraham: testing... |
| 10:26 | <Dashiva> | The expected result is one of all the possible results |
| 10:29 | <Hixie> | jgraham: you just dropping annotations that aren't on headers? |
| 10:30 | <jgraham> | Hixie: For now. Other strageties are welcome |
| 10:30 | <Hixie> | k |
| 10:30 | <Hixie> | seems reasonable |
| 10:36 | <virtuelv> | What's the reasoning behind this wording for window.open? |
| 10:37 | <virtuelv> | "The third argument, features, has no effect and is supported for historical reasons only." |
| 10:38 | <virtuelv> | I know that, for purity and all that is good, it should never have been done that way in the first place |
| 10:39 | <virtuelv> | but are browsers in reality going to drop support for this on the floor? |
| 10:39 | <Hixie> | the only effects it has are UI-based and thus out of scope, i think |
| 10:41 | <virtuelv> | it allows you to set innerHeight/Width |
| 10:41 | <annevk2> | sweet, people worked on the encoding stuff :) |
| 10:41 | <virtuelv> | (although that never seemed to be supported in IE) |
| 10:42 | <adactio> | virtuelv: all of the values in "features" affect the browser window, rather than the document. |
| 10:42 | <adactio> | Hixie: Am I right in thinking that HTML5 defines DOM APIs but steers away from BOM APIs by design. |
| 10:42 | <virtuelv> | adactio: you're right about that |
| 10:43 | <othermaciej> | adactio: what are BOM APIs? |
| 10:43 | <virtuelv> | (affecting the browser Window) |
| 10:43 | <adactio> | othermaciej: Browser Object Model |
| 10:43 | <Hixie> | adactio: not sure what a Browser Object Model API is |
| 10:43 | <othermaciej> | me neither |
| 10:44 | <adactio> | Hixie: it's an ad-hoc term for anything to do with browser chrome: width, height, etc. |
| 10:44 | <Hixie> | virtuelv: innerHeight/Width is a UI issue (e.g. on my work machine, i don't have windows at all, so it won't do anything) |
| 10:44 | <Hixie> | adactio: ah. then no. |
| 10:44 | <Hixie> | adactio: html5 has lots of "BOM" things |
| 10:44 | <adactio> | Hixie: can you give me a quick example? |
| 10:45 | <virtuelv> | Hixie: I understand that, but I think I would like to see this documented still |
| 10:45 | <Hixie> | adactio: window.open(), for example |
| 10:45 | <virtuelv> | it's being used on the web, virtually any day |
| 10:45 | <adactio> | Hixie: Oh, yeah. True. |
| 10:45 | <Hixie> | virtuelv: it doesn't matter how the browsers implement it, so there's not anything to define |
| 10:45 | <othermaciej> | I see you also don't have window.move{To,By} or the resize or scroll methods |
| 10:46 | <Hixie> | that should be in CSSOM, iirc |
| 10:46 | <annevk2> | I haven't specced move or resize |
| 10:46 | <annevk2> | some of scroll is though |
| 10:46 | <Hixie> | i would specify them as not doing anything, if i did spec them |
| 10:47 | <othermaciej> | we have wndow.scrollTo(), scrollBy() and scroll() |
| 10:47 | <othermaciej> | not sure what the difference is |
| 10:47 | <virtuelv> | Hixie: why are the barprop properties still in, then? |
| 10:47 | <annevk2> | i have those othermaciej |
| 10:47 | jgraham | would like author.stopRearragingMyDesktopAlready() |
| 10:47 | <annevk2> | i don't have scrollByLines and other esoteric stuff |
| 10:47 | <Hixie> | virtuelv: because they affect the DOM (you can access them) -- note that they are specced as basically doing nothing useful |
| 10:48 | <othermaciej> | annevk2: we don't have scrollByLines on Window but we do on Element (which seems odd) |
| 10:48 | virtuelv | is confuzzled |
| 10:53 | <jgraham> | Hixie: I think the definition of "Form elements's labelled control" isn't clear about cases like <label><input id=a><input id=b></label> |
| 10:53 | <Hixie> | file a bug |
| 10:53 | <Hixie> | using the little bug filer bar |
| 10:53 | <Hixie> | it's easier to do that than to tell me on irc :-) |
| 10:55 | <jgraham> | irc sometime gives instant feedback of the form "no you idiot…" |
| 10:55 | <jgraham> | Plus I don't like the little comment box |
| 10:56 | <othermaciej> | I wish I could hide the comment box |
| 10:56 | <Hixie> | you can |
| 10:56 | <Hixie> | hit the button on the left |
| 10:56 | <Hixie> | the arrow pointing to the right indicating that clicking it will close the box |
| 10:57 | <annevk2> | hey, RB is back; I think I joked about that last week |
| 10:57 | <othermaciej> | ah, the one that's only visible if I make my window really really wide |
| 10:57 | <annevk2> | something in relation to "silly season" |
| 10:57 | <othermaciej> | thanks, done |
| 10:57 | <Hixie> | jgraham: checked in your annotations, thanks |
| 10:58 | <jgraham> | Great |
| 11:00 | <Hixie> | hm, it ruins the styles of the element sections |
| 11:00 | <Hixie> | oh well |
| 11:02 | <Hixie> | you know |
| 11:02 | <Hixie> | with the new definitions of microdata |
| 11:03 | <Hixie> | we don't even really need to have predefined types anymore |
| 11:03 | <Hixie> | i could just change item=vcard to item=org.w3.vcard |
| 11:05 | <Hixie> | i'll sleep on it and will consider doing that tomorrow |
| 11:05 | <Hixie> | nn |
| 11:06 | <annevk2> | nn |
| 11:06 | <jgraham> | gn |
| 11:28 | <foolip_> | doesn't the new microdata spec suffer from the same problems as prefix solutions? |
| 11:29 | <foolip_> | if you only need to specify a fully qualified identifier on the item type, people might copy just the itemprops and imagine that should somehow work |
| 11:38 | <annevk2> | some of the same, maybe |
| 11:42 | <Dashiva> | I managed to be involved in a conversation put on lastweek without being part of the quote. That's a first. |
| 11:44 | <Philip`> | foolip_: In the old system, if you just copy the itemprops and no item then you won't get any parser output either, so it doesn't seem any more fragile |
| 11:45 | <Dashiva> | Philip`: But suppose you paste it inside another item. Then you'd get an net.something item with a org.whatever property, which is likely to be harmless |
| 11:46 | <Dashiva> | Whereas a net.something item with a generic property name is easy to get overlap with |
| 11:46 | <foolip_> | Dashiva: harmless if they don't share any keywords |
| 11:47 | <foolip_> | Philip`: But the same is also true of prefixes. I happen to not have a big problem with either prefixes or this "from org.w3c.vcard import *", but I'm not sure why they are different and how we can plausibly claim that prefixes are bad while this isn't |
| 11:48 | <foolip_> | but I'm sure this criticism will come (with a vengeance) from others, I don't need to do it for them |
| 11:55 | gsnedders|work | finds TabAtkins writing LOLSPEAK to public-html |
| 11:56 | <foolip_> | standards bodies aren't what they used to... |
| 11:57 | <Dashiva> | So is HTML5 the authority on aria now? |
| 11:57 | <annevk2> | foolip_, they're not? |
| 11:58 | <gsnedders|work> | annevk2: If they were, we'd've done everything WAI said blindingly as if their puppets |
| 11:58 | <foolip_> | annevk2: jk, I wasn't around back then :-/ |
| 12:04 | <annevk2> | foolip_, me neither, so I was interested in knowing :) |
| 12:05 | <foolip_> | I imagine that before there were people from Sun in suits and things like that |
| 12:05 | <foolip_> | maybe even briefcases |
| 12:05 | <Dashiva> | And ties? |
| 12:06 | mpt | tries to use the HTML5 spec to work out how browsers are supposed to handle "<span />", and fails utterly |
| 12:07 | <foolip_> | mpt: for that kind of thing using the HTML5 live dom viewer is nice |
| 12:07 | <Dashiva> | mpt: Handle it how? |
| 12:07 | <mpt> | Dashiva, exactly |
| 12:07 | <foolip_> | http://livedom.validator.nu/ |
| 12:07 | <Dashiva> | No, like, rendering or parsing or what? |
| 12:08 | <gsnedders|work> | mpt: As an open span tag. The / has no effect. |
| 12:08 | <foolip_> | yep, livedom agrees |
| 12:08 | <Dashiva> | Start at http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#tokenization and just follow the steps |
| 12:08 | <gsnedders|work> | (And it'll throw a parse error as the self-closing flag is not acknowledged by the tree builder) |
| 12:08 | <gsnedders|work> | (Then throw another as it isn't closed upon EOF) |
| 12:08 | <mpt> | thanks foolip_ |
| 12:09 | <mpt> | Dashiva, I tried that, and got as far as <http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#close-tag-open-state>; |
| 12:10 | <Dashiva> | How did you get there? |
| 12:10 | <Dashiva> | Tag open state -> Tag name state -> Before attribute name state -> Self-closing start tag state -> back to data state |
| 12:10 | <gsnedders|work> | You start in the data state, you consume the <, then move to the tag open state |
| 12:11 | <gsnedders|work> | From there, you consume the "s" and move to the tag name state |
| 12:11 | <gsnedders|work> | Stay in tag name state for "p", "a", and "n", then consume the space and switch to before attribute name state |
| 12:11 | <mpt> | oh, I see |
| 12:11 | <mpt> | I missed the tag name state part |
| 12:11 | <mpt> | I guess I was trying to skip ahead too quickly |
| 12:11 | <gsnedders|work> | Consume the "/", switch to self-closing start tag state |
| 12:12 | <gsnedders|work> | Consume the ">", set the self-closing flag, then emit the token, and change back to the data state |
| 12:12 | <gsnedders|work> | (The self-closing flag is then ignored in the tree builder) |
| 12:12 | <Dashiva> | (Which is a parse error) |
| 12:13 | <gsnedders|work> | (And then if there's no more data, it hits EOF and throws a parse error because span is still open) |
| 12:13 | <mpt> | I see |
| 12:13 | <mpt> | Thanks very much gsnedders|work and Dashiva |
| 12:18 | <zcorpan> | foolip: prefixes are different because people think prefixes have meaning and write code that acts upon the prefix instead of resolving it, and Selectors interact badly with prefixes |
| 12:20 | <jgraham> | Selectors act badly with unprtefixed things unless handled with care |
| 12:20 | <jgraham> | Unless I am misunderstanding the proposal |
| 12:21 | <jgraham> | *unprefixed |
| 12:22 | <ray> | i wonder if there will be a public awareness campaign about the death of <a name> in html5 |
| 12:22 | <ray> | i only learned that something else was possible a few months ago |
| 12:24 | <hsivonen> | foolip_: xmlns:prefix is having to write import module as prefix |
| 12:24 | <hsivonen> | foolip_: while microdata doesn't let you import away the burned-in prefixes |
| 12:24 | <hsivonen> | foolip_: and Java doesn't let you rename the prefix--it lets you only hide it |
| 12:26 | <hsivonen> | ray: something else has been possible ever since Netscape 4 died |
| 12:26 | <annevk2> | ray, it's being advocated since XHTML was popular |
| 12:27 | <ray> | yeah, i'm speaking from the amateur sometime web developer fog of confusion here |
| 12:27 | <Lachy_> | ray, the number of sites I've seen using <a name=""> seems very low compared with those using id="" |
| 12:28 | <hsivonen> | mpt: the cursor styling of <abbr> on your blog is confusing |
| 12:29 | <hsivonen> | mpt: I get the help cursor when you don't have a title attribute |
| 12:29 | <mpt> | hsivonen, yes, sorry, I've been meaning to fix that |
| 12:30 | <hsivonen> | for a moment, I thought tooltips had regressed on Firefox trunk |
| 12:30 | <annevk2> | ray, any suggestions for such a campaign? |
| 12:31 | <annevk2> | ray, there's a bunch of little things that changed; I guess what's needed in the end is a bunch of tutorials that are spread through blogs/twitter/etc. |
| 12:31 | <annevk2> | s/needed/will do it/ |
| 12:31 | <ray> | i do think a unified "html5 changes" tutorial would be nice |
| 12:32 | <hsivonen> | mpt: regarding the actual content, I think GTK+ and Qt should be like Carbon and Cocoa, and this whole Gnome/KDE divide is harmful to desktop Linux |
| 12:32 | <foolip_> | hsivonen: Good points, but it'd be very enlightening to have a prefix solution tested by Google just to see if users really are more confused. I doubt they're willing to waste time on hypothetical solutions though... |
| 12:32 | <gsnedders|work> | So one should be deprecated, hsivonen? :P |
| 12:34 | <zcorpan> | jgraham: true, it won't work when you have nested items with different types where the different types have properties with the same names |
| 12:36 | <foolip_> | zcorpan: presumably the nested item can't use itemprops from the outer item. you can composite items into bigger items, but not merge them |
| 12:36 | <foolip_> | at least that's what I'd hope |
| 12:38 | <zcorpan> | foolip: right |
| 12:38 | <hsivonen> | gsnedders|work: I want to avoid getting into that debate |
| 12:39 | <zcorpan> | foolip_: so if you have <span item=org.w3.vcard><span itemprop=fn>foo</span><span item=org.example.bar><span itemprop=fn>bar</span></span></span> |
| 12:39 | <hsivonen> | gsnedders|work: I'll leave at this: having to choose between Gnome and KDE is silly and it sucks that Qt apps have wrong-looking widgets on Ubuntu by default |
| 12:40 | <zcorpan> | foolip: you can't get the vcard "fn" without the other without knowing the structure beforehand |
| 12:40 | <zcorpan> | maybe the other item should have an itemprop too |
| 12:41 | <zcorpan> | that allows a nested item |
| 12:41 | <foolip_> | zcorpan: it already works like that |
| 12:41 | <foolip_> | I missed that you hadn't written that in the example |
| 12:41 | jgraham | is confused |
| 12:42 | <zcorpan> | <span item=org.w3.vcard><span itemprop=fn>foo</span><span itemprop=somethingthatallowsanesteditem item=org.example.bar><span itemprop=fn>bar</span></span></span> |
| 12:42 | <foolip_> | zcorpan: exactly |
| 12:42 | <jgraham> | I don't like the idea of having to explicitly mark "this piece of microdata lives inside another, unrel;ated piece of microdata" |
| 12:44 | <zcorpan> | this seems like a reason to prefer the previous proposal |
| 12:44 | <jgraham> | Imagine something like planet where each article could be a com.example.blog item and within each article there could be any arbitary author-supplied microdata |
| 12:48 | <foolip_> | so perhaps the parent-item should have some anonymous child-items |
| 12:49 | <foolip_> | but if they're actually unrelated, perhaps they should be separate items. |
| 12:51 | <jgraham> | foolip_: They are seperate items. But it is convuluted to ensure that they always appear in a seperate subtree |
| 12:51 | <jgraham> | *convoluted |
| 12:51 | <foolip_> | jgraham: you could replace "top-level item" with something that doesn't only have to do with the tree |
| 12:52 | <foolip_> | e.g. any item that doesn't have an itemprop attribute. |
| 12:54 | <jgraham> | foolip_: I'm not sure how that helps with the problem of identifying an item by a selector |
| 12:59 | <foolip_> | jgraham: selectors eh? |
| 13:17 | <annevk2> | foolip_, fwiw, the theory is that implementations have a high-res backend for <canvas> |
| 13:17 | <annevk2> | foolip_, it has been suggested multiple times to do away with this |
| 13:20 | <foolip_> | annevk2: even if they did, why should that leak through the interface (as opposed to just given crisper rendering)? |
| 13:22 | <annevk2> | foolip_, I think the idea is that you want to do filters on the high-res data and not on the premultiplied data |
| 13:23 | <annevk2> | I'm not convinced personally. If people want high-res they should just use a larger <canvas> imo. |
| 13:24 | <zcorpan> | certainly that would be easier to understand |
| 13:25 | <foolip_> | let's hope Hixie sees the light :) |
| 13:54 | <Philip`> | annevk2: That's no good for browser developers who develop browsers for high-DPI displays and want canvases to automatically look nice, without requiring every author to manually make it high-res |
| 13:56 | <gsnedders|work> | Like in cases where 1 CSS pixel != 1 device pixel |
| 13:58 | <annevk2> | Philip`, they already have compat issues anyway (and also, tough luck) |
| 14:03 | <hsivonen> | are hardware devs already a the point where they could double the ppi of a 24" screen? |
| 14:03 | <hsivonen> | aside: what's up with Apple Store? Looks like their product info DB has fallen off |
| 14:03 | <hsivonen> | user ratings, titles and prices show |
| 14:03 | <hsivonen> | pictures and product info doesn't |
| 14:06 | <TabAtkins> | gsnedders|work, I find LOLSPEAK to be the most efficient way to communicate things sometimes. ^_^ |
| 15:26 | annevk3 | somewhat disagrees with <em> and <i> being "veeeeery different" |
| 15:26 | <annevk3> | in practice, anyway |
| 15:27 | <Dashiva> | Semantic Web is just around the corner |
| 15:28 | gsnedders|work | sticks his head around |
| 15:28 | <gsnedders|work> | I don't see it. Maybe it's just very small? |
| 15:29 | <Dashiva> | No, it's just invisible to the naked eye |
| 15:29 | <Dashiva> | It permeates everything |
| 15:41 | GPHemsley | can feel it |
| 15:41 | <GPHemsley> | Ack! It's in my hair. |
| 15:59 | <TabAtkins> | Dashiva: http://echelog.matzon.dk/logs/browse/chromium/1251064800 cliffs notes |
| 18:04 | <Lachy> | woah, who went through the whole spec and spammed the bug form with "add examples here" bugs?! |
| 18:05 | <gsnedders> | Lachy: Lachy |
| 18:05 | <Lachy> | gsnedders, what? |
| 18:06 | <gsnedders> | Lachy: You did. |
| 18:06 | <Lachy> | no I didn't |
| 18:06 | <Lachy> | it might have been Hixie, since he responded to a couple of them with messages to be more specific |
| 18:06 | <jgraham> | It was Hixie |
| 18:07 | <Lachy> | ah, yeah. just got to this one http://www.w3.org/Bugs/Public/show_bug.cgi?id=7323 |
| 18:09 | <gsnedders> | That damned spammer! |
| 19:57 | <Hixie> | i added the example ones cos i needed to get "add examples" off my list of things to do and into a more specific actionable location |
| 20:59 | <Lachy> | Hey Hixie, I got some feedback today from our dev relations team about how web developers really want to be able to be able style the form control validation error messages, without having to use scripts to create their own custom messages |
| 21:00 | <Lachy> | apparently some developers really don't want to use the validation stuff because the error messages are so ugly, at least in Opera. |
| 21:01 | <Lachy> | I know that's one of our implementation issues, but the desire to style the stuff is understandable |
| 21:01 | <TabAtkins> | Yo, JohnResig. |
| 21:02 | <Lachy> | anyway, I said it would probably require the CSSWG to address the issue, perhaps providing some kind of pseudo-element to select the error message content. |
| 21:02 | <TabAtkins> | Lachy: Hmm. We may also need assurances on the internal structure of the error message. Is it just a simple text string right now? |
| 21:03 | <takkaria> | hsivonen: snow leopard release was announced |
| 21:06 | <Lachy> | takkaria, in Opera's implementation, I believe it is just a simple text string in a box with a red border. |
| 21:07 | <Lachy> | s/takkaria/TabAtkins/ |
| 21:07 | <takkaria> | good to know :) |
| 21:07 | <TabAtkins> | Lachy: k. Then yeah, a pseudoelement would work well. We'd just set border, font, color, etc. |
| 21:08 | <TabAtkins> | ::error? |
| 21:08 | <Lachy> | we should ban people from this channel who's nick names start with the same first two letters as someone else's, so that it doesn't mess with tab completion! |
| 21:08 | <gsnedders> | :invalid |
| 21:08 | <gsnedders> | (or maybe ::invalid) |
| 21:08 | <Lachy> | gsnedders, ::invalid (it has to be a pseudo-element) |
| 21:08 | <Lachy> | alternatively, it might be possible to do something with XBL. Not sure how exactly, I'd have to think about it |
| 21:08 | <TabAtkins> | Does anybody implement XBL? |
| 21:09 | <Lachy> | not yet |
| 21:09 | <Lachy> | well, not XBL2. (Mozilla has XBL1) I once heard that WebKit had someone working on it a little. Not sure what the progress is. |
| 21:09 | <TabAtkins> | Hrm. Not sure how you'd use XBL anyway here. It's still a browser-generated element. You'd have to somehow expose it in CSS anyway. Might as well do it with a pseudoelement. |
| 21:10 | <Lachy> | yeah, but XBL will give you a lot more flexibility |
| 21:10 | <Lachy> | but it would still require a selector for it |
| 21:10 | <TabAtkins> | But how would you target it? It's not like, say, <input type=slider>, where you can just point to it with the class or id or whatever you gave it in your html. |
| 21:10 | <TabAtkins> | Yeah. |
| 21:10 | <Lachy> | what do you mean? |
| 21:11 | <TabAtkins> | Well, the error box doesn't appear in your html. So you don't have any hooks to use to target it, whether with CSS or XBL |
| 21:13 | <Lachy> | yeah, the XBL method would need to bind an event listener for the "invalid" event to the control, and provide custom validation. So it's probably around the same amount of complexity as an ordinary script based approach |
| 21:14 | <Lachy> | but in principle, you'd set up your binding with a template that has markup for the control and error message, and have a script in there listening for the event that then controls the whole thing |
| 21:14 | <AryehGregor> | The form errors in Opera do look rather garish, it's true. That isn't stopping me, though, since I have no aesthetic taste. :) |
| 21:15 | <krijn> | We authors want to do all sorts of crazy stuff with error messages |
| 21:15 | <AryehGregor> | There's also not much control over the wording of the messages, while we're at it. That might annoy some people as well. |
| 21:15 | <krijn> | Fade them in, have them have little icons and shadows, tee hee |
| 21:16 | <TabAtkins> | Lachy: Hmm. That's seems annoyingly complex. And it requires scripting, which is annoying. |
| 21:16 | <TabAtkins> | Though, you could use XBL hooked to :invalid to both generate and style the message. |
| 21:17 | <Lachy> | (I suspect the problem with the design of our error messages is that they were done by a programmer in core who also possessed no asthetic taste, and were never touched by anyone in desktop) |
| 21:17 | <TabAtkins> | The problem comes when you automatically generate the message with some method other than XBL, because then you can't interface with it through XBL. I think. |
| 21:19 | <AryehGregor> | Placeholder possibly also needs styling. |
| 21:20 | <TabAtkins> | Possibly. It's certainly a way to round out the set. But placeholders are styled very similarly across sites currently, which says that the need for styling is lesser than for error messages. |
| 21:20 | <krijn> | How do you specify the text for the error message? |
| 21:20 | <AryehGregor> | Yes, agreed. |
| 21:20 | <Lachy> | placeholder should use the system's native style for placeholders |
| 21:20 | <AryehGregor> | krijn, for pattern you can use the title attribute. For the others you don't, AFAIK. |
| 21:20 | <krijn> | Hmm |
| 21:21 | <AryehGregor> | It might be kind of weird if you get a mix of languages that way or such. |
| 21:21 | <TabAtkins> | Indeed. |
| 21:21 | <krijn> | Yeah, marketing people don't like that :) |
| 21:21 | <Lachy> | krijn, if we were to provide a way for authors to specify custom error messages, we would need a way for them to specify errors for all possible errors for each control |
| 21:21 | <krijn> | That's what we already do now |
| 21:22 | <AryehGregor> | Another thing about Opera's implementation is that if the control that has the error isn't currently visible, the error will appear randomly in the middle of nowhere. Not much way to fix that, though, I guess. |
| 21:22 | <AryehGregor> | (It comes up in MediaWiki's Special:Preferences, which uses JS-based tabs.) |
| 21:22 | <Lachy> | doing so currently requires authors to use a script to provide their own complete custom error message, not simply replace the text |
| 21:22 | <krijn> | How I normally do it nowadays: <label>Foo <em>(required)</em> <input> <strong>Error message</strong></label> |
| 21:23 | <krijn> | So that the strong element can be put there with JS |
| 21:23 | <AryehGregor> | krijn, try out Opera's implementation. It's a little pop-up box. |
| 21:23 | <krijn> | Yeah, I know |
| 21:23 | <krijn> | If there's no way to style it, I won't ever use it |
| 21:24 | <AryehGregor> | Yet another issue I noticed with Opera is it only gives the error for the first input. Which might be necessary to stop them from overlapping, but still isn't as nice as you could do manually. |
| 21:24 | <krijn> | (Well, I would, but designers wouldn't) |
| 21:24 | <AryehGregor> | Same here. Probably MediaWiki would use it because we don't really have design people. :D |
| 21:24 | <krijn> | Heh :) |
| 21:25 | <krijn> | Slightly related: how to markup 'this is a required' input in HTML5? |
| 21:25 | <krijn> | <input required> of course |
| 21:25 | <krijn> | But how's that presented to the user? |
| 21:25 | <TabAtkins> | You can do :required, if the browser's implementing things correctly. |
| 21:25 | <krijn> | Most designs have some kind of asterisk next to or inside the label |
| 21:25 | <AryehGregor> | You have to use CSS. |
| 21:25 | <TabAtkins> | Then use either direct styling, or ::before/::after |
| 21:26 | <krijn> | Then you will target the input |
| 21:26 | <krijn> | Hmm |
| 21:26 | <AryehGregor> | Every browser that supports required also supports generated content, so you're good. ;) |
| 21:26 | <TabAtkins> | I've used class=required on my inputs before, and used ::before{ content: "* " }; |
| 21:26 | <AryehGregor> | Don't care much for IE users? |
| 21:26 | <Lachy> | krijn, just use <label>Name (required) <input type=text required></label> (or use a * instead of (required)) |
| 21:27 | <TabAtkins> | No. No I don't. Screw them. |
| 21:27 | <TabAtkins> | They can just deal with the error messages when they try to submit. |
| 21:27 | <Lachy> | TabAtkins, even IE8 users? |
| 21:27 | <AryehGregor> | That's my attitude too! |
| 21:27 | <krijn> | Lachy: that's what I do now, yes |
| 21:27 | <gsnedders> | Lachy: ::before doesn't work in IE8 |
| 21:27 | <krijn> | It doesn't? |
| 21:27 | <gsnedders> | :before doe |
| 21:28 | <gsnedders> | *does |
| 21:28 | <TabAtkins> | Crap, ::before *still* doesn't work there? I haven't tested yet. |
| 21:28 | <krijn> | Ah :) |
| 21:28 | <Lachy> | gsnedders, :before works |
| 21:28 | <AryehGregor> | We don't bother with client-side form validation at all now, so if browsers don't implement HTML 5 forms, no loss. :) |
| 21:28 | <TabAtkins> | That's dumb. |
| 21:28 | <AryehGregor> | Well, it was originally :before, wasn't it? |
| 21:28 | <Lachy> | yeah, it's one of those things that the IE team failed to add because they were focussing on implementing just CSS2.1 and no-one thought to add support for the ::before/::after ones as well |
| 21:28 | <AryehGregor> | I actually forgot that it's supposed to be ::before these days. |
| 21:29 | <TabAtkins> | I learned the pseudoelement/pseudoclass distinction immediately, so it's *always* been wrong when I see :before |
| 21:29 | <Lachy> | When I asked cwilso about it before IE8 shipped, he said it was too late to get it in on time :-( |
| 21:30 | <TabAtkins> | ...It's too hard to put in an extra :. Ok, whatever. |
| 21:30 | <AryehGregor> | Well, there's such a thing as feature freeze. |
| 21:31 | <krijn> | They were too busy breaking other stuff ;o) |
| 21:31 | <Lachy> | damn, I'm getting 47% packet loss on my connection today. No wonder things are slow and keep dropping off :-( |
| 21:31 | <krijn> | Like button:active and background-position |
| 21:31 | <AryehGregor> | If you start doing stuff like that, then you're starting to add lots of little new features when you're supposed to be fixing bugs. |
| 21:33 | <TabAtkins> | Yeah, but that's a syntax bug. |
| 21:33 | <AryehGregor> | Not in CSS 2.1 . . . |
| 21:33 | <AryehGregor> | http://www.w3.org/TR/CSS2/generate.html#before-after-content |
| 21:33 | <Philip`> | Lachy: You should run a script that sends dummy UDP packets to fill up that 47% of your connection, so you can use the remaining 53% for uninterrupted loss-free connections |
| 21:34 | <TabAtkins> | AryehGregor, when was it fixed then? |
| 21:35 | <AryehGregor> | TabAtkins, http://www.w3.org/TR/css3-selectors/#pseudo-elements |
| 21:35 | <AryehGregor> | "This :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements. For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2 (namely, :first-line, :first-letter, :before and :after). This compatibility is not allowed for the new pseudo-elements introduced in this specific |
| 21:35 | <AryehGregor> | ation." |
| 21:35 | <AryehGregor> | It's not a syntax error, it's explicitly allowed. |
| 21:36 | <TabAtkins> | Ah, I got messed up. |
| 21:36 | <TabAtkins> | I was referring to the bug being *not* recognizing the :: syntax. |
| 21:36 | <AryehGregor> | I just use :before and :after, personally. |
| 21:36 | <AryehGregor> | Well, IE8 recognizes (almost?) no CSS 3. |
| 21:36 | <TabAtkins> | Yeah. |
| 21:41 | <TabAtkins> | So, pseudoelement for error messages? Then we can use content: to control the text. |
| 21:41 | <AryehGregor> | How would you know what the error was in CSS? |
| 21:41 | <TabAtkins> | A pseudoclass, obviously. ^_^ |
| 21:41 | <AryehGregor> | Um, I guess that could work. |
| 21:41 | <TabAtkins> | input[type=number]:out-of-range::error { content: "You're out of range."; } |
| 21:42 | <AryehGregor> | Probably better to use functional notation for the pseudoclass to avoid creating twenty of them . . . |
| 21:42 | <TabAtkins> | Was just about to suggest that. |
| 21:42 | <TabAtkins> | input:invalid("out-of-range")? |
| 21:43 | <AryehGregor> | Maybe. |
| 21:44 | <AryehGregor> | You'd want to have access to the title of the element, for pattern mismatches. |
| 21:44 | <Lachy> | AryehGregor, yeah, I had that a similar idea ealier, but wasn't sure what could be put in as identifiers for each error |
| 21:45 | <AryehGregor> | It sounds doable. |
| 21:45 | <TabAtkins> | AryehGregor, yeah, you can do that in content with the attr() function. |
| 21:46 | <AryehGregor> | TabAtkins, but this is a pseudoelement. Does attr() make any sense for pseudoelements? |
| 21:47 | <Lachy> | AryehGregor, yes |
| 21:47 | <AryehGregor> | It seems so. |
| 21:47 | <TabAtkins> | Hrm, you're right. It may. After all, pseudoelements *can't* have attributes, so it may make sense to say that the function draws from the superior parent (using Hixie's terminology in Generated content) |
| 21:47 | <AryehGregor> | That works fine, then. |
| 21:47 | <AryehGregor> | TabAtkins, Generated Content already says that, it seems. |
| 21:47 | <Lachy> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%0D%0Ap%3A%3Abefore%20%7B%20content%3A%20attr(title)%20%22%20%22%3B%20%7D%0D%0A%3C%2Fstyle%3E%0D%0A%3Cp%20title%3D%22attr%22%3Etest |
| 21:47 | <AryehGregor> | Example: [href]::after::alternate { content: attr(href); } |
| 21:47 | <TabAtkins> | Excelelnt. |
| 21:48 | <TabAtkins> | Ignoring the ::alternate, doesn't that already work actually? |
| 21:48 | <Lachy> | AryehGregor, what's the ::alternate pseduo element? |
| 21:48 | <AryehGregor> | I have no idea. |
| 21:48 | <AryehGregor> | I was just searching the spec for attr(). :) |
| 21:48 | <Lachy> | also, you're only allowed to use one pseudo-element per selector |
| 21:48 | <AryehGregor> | http://www.w3.org/TR/css3-content/#inserting1 |
| 21:49 | <TabAtkins> | ::alternate is a magic element in Generated Content used for some of the magic algorithms, like footnotes. |
| 21:49 | <TabAtkins> | And Generated Content relaxes that one-pseudoelement restriction. |
| 21:49 | <Lachy> | oh, they must have changed that syntax rule |
| 21:49 | <AryehGregor> | I was quoting an example from the spec. I think its editor hangs out here, you could ask him. :) |
| 21:49 | <TabAtkins> | Note: Generated Content is several years idle, I believe. |
| 21:49 | <TabAtkins> | Probably since Hixie took up html5. |
| 21:50 | <AryehGregor> | Undoubtedly. |
| 21:50 | <JonathanNeal> | YeahTML 5! |
| 21:50 | <Lachy> | ah, yeah, I remember now. That has been in there a while. I don't think such chaining is supported by any browsers though, which is why I'd forgotted about it |
| 21:51 | <TabAtkins> | And yes, a::after {content: attr(href);} works as expected, by drawing from the superior parent (the a). |
| 21:54 | <TabAtkins> | Lachy: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-constraint-validation-api |
| 21:54 | <TabAtkins> | For source of values for the :invalid() pseudoclass |
| 21:55 | <TabAtkins> | We'd probably want to switch it to using css-dashes rather than camelCase. |
| 21:55 | <AryehGregor> | Or else go like currentColor and introduce inconsistent to match other specifications. |
| 21:56 | <AryehGregor> | inconsistency |
| 21:56 | <TabAtkins> | Nah, screw that. There's a well-defined and unambiguous mapping, so we should use it to maintain internal consistency. |
| 21:56 | <AryehGregor> | That's my attitude too. currentColor is ugly. |
| 21:57 | <TabAtkins> | You'll never see a dash appear in those, because it's not allowed in an identifier name in js if you want to use the . syntax to access it. |
| 21:57 | <TabAtkins> | And since that's way more convenient, nobody ever puts dashes in their identifiers. |
| 22:00 | <TabAtkins> | Hmm. If I'm doing a simple page with a single section, do I need <article>? Or am I fine with just making <header> a child of <body>? |
| 22:04 | <Lachy> | yes, body is a sectioning element. No need for an extra <section> or <article> |
| 22:05 | <Lachy> | in fact, using a redundant section within body is technically wrong |
| 22:05 | <TabAtkins> | Thought so, but didn't want to check the spec. |
| 22:05 | <Lachy> | no worries. Asking in here is often a good enough substitute for checking the spec |
| 22:07 | <JonathanNeal> | Lachy, that's my favorite thing about this channel. |
| 22:07 | <JonathanNeal> | I've been able to understand the spec so much easier and so much faster thanks to the input here. |
| 22:09 | <TabAtkins> | Think I should ping the CSS list with suggestion about :invalid()? |
| 22:10 | <Lachy> | TabAtkins, go ahead |
| 22:11 | <AryehGregor> | Hmm, I guess :invalid() would be useful even without ::error. |
| 22:11 | <Lachy> | TabAtkins, is the idea to replace all those new pseudo-classes in HTML5 with a single :invalid(...); pseudo-class? |
| 22:11 | <TabAtkins> | Possibly. I need to go check the html5 pseudoclasses again. I know I saw them just a few days ago. |
| 22:13 | <TabAtkins> | All right, found them. |
| 22:13 | <TabAtkins> | Yeah. There's only one of them so far - :out-of-range - plus its converse. |
| 22:14 | <TabAtkins> | So I'd replace that with :invalid(range-underflow) and :invalid(range-overflow), and add all the other types of invalidity. |
| 22:15 | <TabAtkins> | Is there a good use for :valid()? Hixie has :valid and :invalid, plus :in-range and :out-of-range. |
| 22:15 | <TabAtkins> | I guess it's equivalent to :not(:invalid(range-overflow)). |
| 22:15 | <AryehGregor> | What would :valid() even mean? |
| 22:15 | <TabAtkins> | But that's a mouthful. |
| 22:15 | <AryehGregor> | Hmm, I see. |
| 22:15 | <AryehGregor> | I don't how it would be used |
| 22:15 | <AryehGregor> | . |
| 22:16 | <TabAtkins> | Presumably however Hixie is imagining :in-range would be used, I dunno. |
| 22:16 | <AryehGregor> | Actually, without ::error I'm not totally sure how :invalid() would be used. Unless you want to fake up your own inline error messages pre-submit? |
| 22:17 | <TabAtkins> | For now, yeah, faking up your own messages. Hopefully Opera would implement ::error at the same time, so we could display:none it for now, and use it properly once more browsers support ::error |
| 22:21 | <AryehGregor> | What's the logic in display: noneing it if it's styleable? |
| 22:21 | <fantasai> | Is there a way to indicate the target medium/media for a particular page? |
| 22:21 | <fantasai> | e.g. "This should be rendered in presentation mode if you have one" |
| 22:21 | <AryehGregor> | That's what we were just discussing on www-style, isn't it? Apparently there's not. |
| 22:22 | <fantasai> | was just wondering if the discussion had already happened for HTML5 |
| 22:23 | <gsnedders> | I don't remember it happening. |
| 22:24 | <fantasai> | ok, somebody should forward it there, then |
| 22:24 | <gsnedders> | I guess you couldn't even do anything with pure CSS to do that… |
| 22:24 | <fantasai> | we could |
| 22:24 | gsnedders | is hundreds of emails behind on www-style :D |
| 22:24 | <fantasai> | I'm not convinced we should |
| 22:25 | <gsnedders> | (I meant currently) |
| 22:25 | fantasai | wonders if that's just the gradient syntax discussion ;) |
| 22:25 | <gsnedders> | fantasai: I saw that thread was long, but no, a lot more than that :) |
| 22:25 | <AryehGregor> | I just archive those as fast as they come in. :P |
| 22:25 | <AryehGregor> | Relevant thread: http://lists.w3.org/Archives/Public/www-style/2009Aug/0338.html |
| 22:25 | <gsnedders> | Oh, I obviously did "mark all as read" in www-style a few days ago, so I'm only 30 behind :P |
| 22:26 | <fantasai> | I never do that. I just have folders that are mostly unread. Like the whatwg folder.... |
| 22:26 | <gsnedders> | If we do want to do that, I'd say I'd prefer it to be in CSS |
| 22:27 | <gsnedders> | fantasai: Well, I skim the subject lines at least |
| 22:27 | <gsnedders> | But I generally don't do much with layout anyway |
| 22:29 | <fantasai> | gsnedders: Like, an @target-media rule? |
| 22:29 | <gsnedders> | fantasai: I dunno. I write so little CSS I can speak neither as an author or implementer. :P |
| 22:30 | <gsnedders> | But yeah, an at-rule seems about as sane as you could get |
| 22:30 | <TabAtkins> | AryehGregor: You'd display:none the ::error because otherwise you get *both* faked up error messages and the real ::error messages. |
| 22:31 | <TabAtkins> | Once enough browsers support ::error, you stop doing that and just style ::error |
| 22:31 | <AryehGregor> | ::error is only going to show up when the user submits the form, right? |
| 22:31 | <gsnedders> | Now, I need to sleep and stop claiming I have any idea about CSS :P |
| 22:31 | <AryehGregor> | So you'd be having the full error message displayed always, even when the user first loads the empty form? |
| 22:31 | <TabAtkins> | Man, really? I read *every single* www-style and whatwg email. I'll occasionally skim the htmlwg ones, but I still open them up. |
| 22:32 | <gsnedders> | I read everything on whatwg and public-html |
| 22:32 | <TabAtkins> | AryehGregor: no, just when they're invalid, and thus matching the :invalid() class. |
| 22:32 | <gsnedders> | I used to read www-style when I did more layout stuff |
| 22:33 | <TabAtkins> | Also, if any of you are using mail clients that don't group threads, I apologize for the gradient discussion. ^_^ |
| 22:33 | <gsnedders> | People use mail clients that don't? :P |
| 22:33 | <AryehGregor> | TabAtkins, which will mean, e.g., every required field in a newly-loaded blank form. Or a field that's not required but has a pattern/min/max/etc., and it isn't met when the user hits the first character. Then the message will show up while the user is still typing. |
| 22:34 | <TabAtkins> | AryehGregor: they should match using the same rules that would be used to display ::error, shouldn't they? Or do those *only* display on form submit? |
| 22:34 | <AryehGregor> | Well, currently Opera only displays errors on form submit. |
| 22:34 | <AryehGregor> | I guess the spec doesn't say? |
| 22:34 | <TabAtkins> | Let me check - not sure |
| 22:34 | <gsnedders> | Spec doesn't say |
| 22:34 | <gsnedders> | Impl. detail |
| 22:35 | <gsnedders> | fantasai: On the whole, to give my opinion, I don't think we really should have target-media or anything like that |
| 22:35 | <AryehGregor> | I think good UI here would be to display the error once the user has filled out that field and moved to a different one, at least for fields where the default value is valid. But I don't do UI. :) |
| 22:35 | <fantasai> | gsnedders: How would you solve the problem Opera's using @media to hack around? |
| 22:35 | <TabAtkins> | That's what I do in my timesheet/journal app I designed for work. |
| 22:36 | <TabAtkins> | I don't mark as invalid until they trigger a change event, but I check for validity on keypress. |
| 22:36 | <TabAtkins> | Otherwise :invalid and :out-of-range as described in html5 are largely useless. |
| 22:39 | <AryehGregor> | I tried using :invalid, but dropped it because it put annoying exclamation points or whatever everywhere in newly-loaded forms. |
| 22:39 | <TabAtkins> | So then it *is* useless in practice. |
| 22:39 | <TabAtkins> | That needs to be changed. |
| 22:39 | <TabAtkins> | But is that a spec-level thing, or a browser-bug thing? |
| 22:39 | <AryehGregor> | It's spec-level. The spec says :invalid matches any element that's in the invalid state. |
| 22:40 | <TabAtkins> | Gotcha. |
| 22:40 | <AryehGregor> | (without actually double-checking to make sure) |
| 22:40 | <AryehGregor> | So yeah, I don't actually see any good use for that. |
| 22:40 | <TabAtkins> | Nah, you're right. |
| 22:40 | <TabAtkins> | So html5 has to change. |
| 22:40 | <TabAtkins> | I'll file a bug! Woo! |
| 22:40 | <AryehGregor> | What should it say? |
| 22:40 | <AryehGregor> | This stuff is more subtle than I initially thought. |
| 22:40 | <AryehGregor> | Probably because I don't know anything about UI. :) |
| 22:40 | <AryehGregor> | (despite writing lots of it, hurrah) |
| 22:41 | <TabAtkins> | Well, as a first approximation, only mark as invalid on a change event, but mark as valid on keypress. |
| 22:41 | <TabAtkins> | Sexy that up as appropriate. |
| 22:41 | <AryehGregor> | Is it appropriate for the spec to dictate the exact time that the error pops up? |
| 22:42 | <TabAtkins> | It's only dictating when a pseudoclass applies. |
| 22:42 | <TabAtkins> | And I think that *is* appropriate. |
| 22:42 | <AryehGregor> | Hmm. |
| 22:42 | <AryehGregor> | But ::error would be left vague? |
| 22:42 | <TabAtkins> | Yeah, I'm fine with that. |
| 22:42 | <AryehGregor> | Actually, do we even need ::error if :invalid is redefined like this? |
| 22:43 | <AryehGregor> | UAs could just use :invalid and generated content, and authors who want to override it can just put in their own CSS rules. |
| 22:43 | <TabAtkins> | Depends. ::error lets UAs do fun things like producing a popup on form submit. |
| 22:43 | <AryehGregor> | A style-able popup? |
| 22:43 | <TabAtkins> | If you have ::error, then yes. |
| 22:43 | <TabAtkins> | At least to some degree. |
| 22:43 | <TabAtkins> | Presumably a plain text string now, XBL to wrap it in fanciness later. |
| 22:43 | <AryehGregor> | Popups usually don't have arbitrary style. They're part of the browser UI, not the site. |
| 22:44 | <AryehGregor> | Hmm. |
| 22:44 | <TabAtkins> | Well, whatever Opera does now. |
| 22:44 | TabAtkins | goes to investigate Opera behavior. |
| 22:44 | <AryehGregor> | That's just some kind of box that gets overlaid on the content. |
| 22:44 | <AryehGregor> | It's not interactive, I don't think. |
| 22:45 | <AryehGregor> | (I don't remember, and my Opera is kind of broken right now.) |
| 22:45 | <TabAtkins> | Hm, I've got Opera beta 2, and I'm submitting an empty <input required>. Is that supposed to happen? |
| 22:46 | <AryehGregor> | You mean 10.00 beta 2? |
| 22:46 | <AryehGregor> | No, didn't happen for me. |
| 22:46 | <TabAtkins> | Yeah, 10b2 |
| 22:47 | <TabAtkins> | <!DOCTYPE html><title>Test</title><form><input required><input type=submit></form> |
| 22:47 | <TabAtkins> | This is submitting without an error for me. |
| 22:47 | <AryehGregor> | You don't have anyplace it's submitting to . . . |
| 22:48 | <TabAtkins> | That should default to submitting to the current page. |
| 22:48 | <AryehGregor> | Hmm, really? |
| 22:48 | <TabAtkins> | I depend on that behavior! |
| 22:48 | <TabAtkins> | Works in IE and FF, at least. |
| 22:49 | <TabAtkins> | Ah, it was the lack of a @name that was screwing it up |
| 22:49 | <AryehGregor> | I actually always have to look up the syntax for <form>. I practically never make a new one, I just fiddle with existing ones. Or use various abstraction layers. |
| 22:49 | <AryehGregor> | Oh, right. |
| 22:49 | <AryehGregor> | inputs with no name are exempt from constraint validation. |
| 22:49 | <TabAtkins> | Nameless inputs aren't succeessful. |
| 22:49 | <TabAtkins> | Yeah. |
| 22:49 | <TabAtkins> | Okay, so opera currently just has a magically positioned box with a simple text and border. |
| 22:50 | <AryehGregor> | Yeah. |
| 22:50 | <TabAtkins> | That *should*, in a perfect world, be styleable with ::error |
| 22:50 | <TabAtkins> | Though how to reproduce the positioning I dunno. |
| 22:50 | <AryehGregor> | What if another browser puts it in a totally different place? |
| 22:50 | <TabAtkins> | I might be okay with leaving that up to the UA if it acts like abspos and dosn't push my design around. |
| 22:51 | <AryehGregor> | This sounds like it will need a lot of thought and authoring experience. |
| 22:51 | <TabAtkins> | Indeed. To the list! |
| 22:52 | <TabAtkins> | (Actually, I have *got* to finish this page for work today. I'll go to the lists in an hour.) |