| 00:38 | <smaug____> | could someone remind me what is the use case for <iframe srcdoc="..."> which can't be handled with data urls? |
| 00:39 | <TabAtkins> | srcdoc has much easier escaping requirements. |
| 00:40 | <TabAtkins> | To securely escape @srcdoc, you only need to escape your quoting character. (You also want to escape &, but that's not necessary for security.) |
| 00:41 | <smaug____> | but no different use cases |
| 00:42 | <smaug____> | just thinking whether to implement it |
| 01:29 | <Hixie_> | smaug____: srcdoc="" is basically equivalent to data:, but has the huge advantage that it is actually readable in the source (e.g. you don't have to escape ' '). |
| 01:33 | <TabAtkins> | Also, if you're using DOM to set it, it's literally nothing more than "iframe.srcdoc = text;". No escaping at all is required. |
| 01:34 | <Hixie_> | indeed |
| 01:34 | <Hixie_> | so in conclusion, it's just convenience, but it's _really_ much more convenient. :-) |
| 01:36 | <smaug____> | k |
| 05:10 | <annevk> | krijn: server does not appear to be responding |
| 05:15 | <annevk> | TabAtkins: not sure that being nr. 1 on the IRC stats is actually an accomplishment or just an indication I don't do much at all :-) |
| 06:05 | <annevk> | hmm |
| 06:05 | <annevk> | should TextEncoder support encoding to utf-16/ut16-be? |
| 06:05 | <annevk> | utf-16be doh |
| 06:32 | <annevk> | optional DOMString label = "utf-8" // this is fine right? |
| 06:36 | <hsivonen> | sigh. code is so broken |
| 06:37 | <hsivonen> | The HTML WG generates too much bug spam these days. I wonder if it’s possible to create a filter that shows only the resolutions that need objecting to. |
| 06:38 | <hsivonen> | maybe I should send it all to /dev/null |
| 06:38 | <hsivonen> | and public-html, too |
| 07:02 | <Stevef__> | hsivonen: morning, on list you wrote "if the <main>element is used in a conforming way, it won't have a <p> element preceding it anyway." what effect does having the p element preceding have on parsing? |
| 07:04 | <annevk> | Stevef__: <p> is normally closed by block-level elements |
| 07:04 | <annevk> | euh I mean, whatever we call block-level these days :) |
| 07:05 | <Stevef__> | annevk: ah OK understand now, thanks! |
| 07:05 | <hsivonen> | Stevef__: what annevk said |
| 07:07 | <annevk> | I don't really understand the fear of changing the parser btw |
| 07:07 | <annevk> | I kinda thought the whole point of having it defined was so we could make changes |
| 07:11 | <hsivonen> | annevk: it doesn’t really help authors to get subtly different results in parsers of different vintage |
| 07:11 | <hsivonen> | annevk: with with the UA stylesheet, you can always deal with differences by putting main { display: none; } in your author stylesheet |
| 07:12 | <hsivonen> | annevk: I thought the point of having it defined was making it the same everywhere |
| 07:12 | <hsivonen> | so I search for list:(public-html.w3.org) in Gmail and it doesn’t find anything older than September 28 |
| 07:13 | <hsivonen> | bug or feature? |
| 07:13 | <Stevef__> | hsivonen: :-) |
| 07:13 | <annevk> | I kinda see it as making the baseline much stronger, but I don't like clinging to the baseline that much. If it makes sense to introduce a parser change, I'm all for another five years of instability around that particular feature. |
| 07:14 | <annevk> | Introducing <intent> for instance does not seem that harmful to me and long term it's probably better. (Assuming we want intents at all, I don't really have an opinion on that.) |
| 07:16 | <hsivonen> | annevk: making <main> close <p> would be relatively harmless and would have a transition story |
| 07:17 | <hsivonen> | annevk: <intent> has no sane transition story |
| 07:17 | <hsivonen> | annevk: it worries me that you think <intent> would not be harmful |
| 07:17 | <annevk> | https://twitter.com/miketaylr/status/258613311057309696 this is great |
| 07:18 | <annevk> | hsivonen: now all browsers are updating having a transition story seems less necessary, breaking compat is still to be avoided |
| 07:20 | <hsivonen> | annevk: Android stock and IE are updating but not cleaning up after themselves yet |
| 07:21 | hsivonen | also expects time warp-stuck copies of Presto to live on all sorts of devices |
| 07:21 | <annevk> | obviously it's better to not introduce breakage, but the reality is that a lot of things will be broken on those older browsers already |
| 07:22 | <annevk> | and the sites where these new features would see adoption first are likely to already be rendering badly |
| 07:24 | <annevk> | The main reason I think breakage is okay is that I think usability and aesthetics of the APIs we introduce matter |
| 07:28 | <annevk> | Anyone know why http://wiki.whatwg.org/wiki/StringEncoding#TextDecoder decode()'s first argument would be optional? |
| 07:29 | <annevk> | gonna change that for now |
| 07:31 | <hsivonen> | I wonder why cwilso rejoined the HTML WG |
| 07:34 | <annevk> | distributed extensibility! |
| 07:38 | <MikeSmith_> | hsivonen: if you have suggestions for changing the bugmail config for public-html, please tell the chairs |
| 07:39 | <MikeSmith_> | right now as far as I can recall it's set up so that only messages for new bugs go to the list |
| 07:39 | <MikeSmith_> | I'd rather no bugmail at all went to the list |
| 07:41 | <MikeSmith_> | btw I thought there was user option in modern bugzilla for subscribing to bugmail for specific components |
| 07:42 | <MikeSmith_> | I can't find any option for it in the version we're running now |
| 07:42 | <MikeSmith_> | which I think is 4.2.3 |
| 07:55 | <hsivonen> | MikeSmith_: I have already told the chairs. |
| 07:55 | <hsivonen> | MikeSmith_: My communication with the chairs does not seem to be useful. |
| 07:55 | <MikeSmith_> | ah ok |
| 07:55 | <hsivonen> | MikeSmith_: It seems it would be rational to stop communicating with the Chairs and go write some software. |
| 07:56 | <MikeSmith_> | the last time I tried to have a discussion about it the response I got was "nobody else has complained" |
| 08:14 | <zcorpan> | krijn: down? |
| 08:14 | <krijn> | Meh, yeah |
| 08:17 | hsivonen | realizes public-webapps has bugspam, too |
| 08:18 | <jgraham> | I quite like that bugspam |
| 08:18 | <krijn> | I'm more into hugspam |
| 08:18 | hsivonen | creates a filter to make IndexedDB disappear |
| 08:20 | <hsivonen> | no wonder why my Bugzilla label was always so full of stuff I didn’t want to see |
| 08:20 | <hsivonen> | (I already had a generic filter to move discussion list bugspam among all other bugmail) |
| 08:22 | <zcorpan> | Hixie_: i read logs, so you can just pretend i'm here and i'll respond 12h later :-P |
| 08:23 | <zcorpan> | (well i *usually* reads logs; email is a safer bet) |
| 08:24 | <hsivonen> | zcorpan: logs are not responding |
| 08:24 | <zcorpan> | hsivonen: logbot is |
| 08:29 | <zcorpan> | anyone object to me removing this dir? http://w3c-test.org/webapps/tests/ |
| 08:29 | <jgraham> | Not me |
| 08:30 | <zcorpan> | a bit annoying that html and webapps have different structure |
| 08:30 | <zcorpan> | both broken |
| 08:30 | <jgraham> | I was going to say :) |
| 08:30 | <Ms2ger> | Yes |
| 08:30 | <zcorpan> | can we fix it? what should it be like instead? |
| 08:31 | <Ms2ger> | I added that dir back because links were broken |
| 08:31 | <zcorpan> | i can put in a htaccess that redirects |
| 08:31 | <Ms2ger> | If that works, sure |
| 08:31 | <jgraham> | Ms2ger: Can't you fix the links? |
| 08:34 | <annevk> | zcorpan: wait, is that the dir with XHR in it? |
| 08:34 | <annevk> | zcorpan: because then you're breaking links on w3.org |
| 08:34 | <annevk> | zcorpan: but maybe I should stop caring about that |
| 08:36 | <zcorpan> | annevk: look closer |
| 08:37 | <zcorpan> | which links are we talking about? |
| 08:40 | <annevk> | the link towards http://w3c-test.org/webapps/tests/XMLHttpRequest/info.htm |
| 08:40 | <annevk> | from the XHR CR |
| 08:40 | <annevk> | which is kinda impossible to find right now, but it did exist |
| 08:41 | <annevk> | ah, http://www.w3.org/TR/XMLHttpRequest1/ |
| 08:41 | <annevk> | http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/ "test suite" |
| 08:51 | <SimonSapin> | "There is a good chance a test suite for XMLHttpRequest will be placed around here." :) |
| 08:54 | <zcorpan> | ok, i'll put in a 301 redirect from http://w3c-test.org/webapps/tests/XMLHttpRequest/info.htm to http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/info.htm |
| 09:01 | <annevk> | the original location was much better :-) |
| 09:04 | <zcorpan> | sigh. why does the redirect not work? |
| 09:16 | <zcorpan> | annevk: maybe say "Implementations that do not implement the DOM" instead of "Non-browser implementations"? |
| 09:17 | <annevk> | hmm, maybe non-JavaScript implementations but I would not want to require Node for instance... |
| 09:21 | <annevk> | Ms2ger: liked my hack to Anolis? |
| 09:21 | <annevk> | Ms2ger: I think something went wrong again with branches btw |
| 09:21 | <annevk> | Ms2ger: sucky branches |
| 09:22 | <zcorpan> | annevk: is the BOM not consumed in streaming mode? |
| 09:23 | <annevk> | zcorpan: it is |
| 09:23 | <annevk> | zcorpan: there's a subtle difference between the streaming flag and the stream variable and I abuse it |
| 09:24 | <zcorpan> | annevk: i'm confused |
| 09:25 | <annevk> | the first time you invoke decode() with stream set to true the streaming flag will be unset |
| 09:25 | <annevk> | the second time you invoke decode() you don't want a BOM to be removed anymore |
| 09:26 | <annevk> | unless I guess you feed it one byte at a time |
| 09:26 | <Ms2ger> | annevk, haven't looked yet |
| 09:26 | <zcorpan> | oh, i see. it would be less confusing if that was called something like "decode has been invoked before" or some such |
| 09:26 | <annevk> | if feeding it one byte at a time is a reasonable scenario we'll need a "seen BOM flag" too |
| 09:27 | <zcorpan> | ah. yeah. |
| 09:27 | <zcorpan> | that should just work, really |
| 09:27 | <zcorpan> | i mean, stream should work with arbitrary chunks |
| 09:28 | <annevk> | I guess yeah, but then I need even more changes I just realised :/ |
| 09:30 | <jgraham> | Yeah, you have to work feeding it one byte at a time |
| 09:31 | <zcorpan> | annevk: "If encoding is failure, or is none of utf-8, utf-16, and utf-16be, throw a "EncodingError"." doesn't NotSupportedError make more sense here? |
| 09:32 | <annevk> | the annoying thing is that then I need to define the actual buffer semantics |
| 09:33 | <annevk> | zcorpan: that comment seems appropriate for the list |
| 09:34 | <zcorpan> | annevk: is there a bugzilla component? |
| 09:34 | <annevk> | zcorpan: doesn't test.w3.org exist for cross-origin tests? |
| 09:34 | <annevk> | zcorpan: yes |
| 09:35 | <annevk> | zcorpan: not sure jsbell will see that though |
| 09:35 | <jgraham> | Cross origin tests? |
| 09:35 | <zcorpan> | annevk: www1.w3c-test.org exists for cross-origin tests. w3c-test.org was introduced because tests can't be trusted to not do damage to w3.org. |
| 09:35 | <jgraham> | Ah, what zcorpan said |
| 09:35 | <jgraham> | Gazumped |
| 09:36 | <zcorpan> | annevk: can you add the file bug script? |
| 09:36 | <annevk> | it's there |
| 09:36 | <jgraham> | Oh, that word doesn't actually seem to have the sense I thought it did |
| 09:36 | <annevk> | oops, doesn't link to the right place |
| 09:38 | <zcorpan> | jgraham: what did you think it means? (i haven't heard that word before) |
| 09:39 | <jgraham> | I was thinking it could be used in a generic sense to mean that you were working on something, and at the last minute someone else came in first with something better than your offering |
| 09:40 | <annevk> | zcorpan: fixed link |
| 09:40 | <annevk> | will fix the decode situation later |
| 09:40 | <jgraham> | But it seems that it is more narrowly defined to be about commercial transactions |
| 09:40 | <annevk> | need some kind of decode algorithm that keeps track of the buffer |
| 09:40 | <annevk> | :( :( :( |
| 09:44 | <zcorpan> | annevk: filed a bug |
| 09:47 | <krijn> | Hmpf, power outage, again |
| 09:49 | <zcorpan> | krijn: you should install a backup battery |
| 09:58 | <hsivonen> | long ISSUE is long: http://www.w3.org/2001/tag/group/track/issues/57 |
| 10:06 | <zcorpan> | i read the description and i don't understand what the issue is |
| 10:21 | <hsivonen> | The Microdata API has revealed multiple incompatibilities with Web content after Firefox 16 went to release |
| 10:22 | <hsivonen> | I wonder why these weren’t already discovered and reported by Opera |
| 10:22 | <jgraham> | hsivonen: Examples? |
| 10:22 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=763229 |
| 10:23 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=801988 |
| 10:23 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=802548 |
| 10:23 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=800850 |
| 10:23 | <hsivonen> | https://bugzilla.mozilla.org/show_bug.cgi?id=802874 |
| 10:31 | <jgraham> | hsivonen: Not sure if/why we didn't find those (maybe they got site-patched?), but they mostly seem to have been solved by evangelism |
| 10:31 | <jgraham> | Would be really nice if people could be convinced that making up their own attributes/elements is badness though |
| 10:34 | <zcorpan> | as well as setting properties on elements, right? |
| 10:57 | <jgraham> | Yeah, generally messing with platfoem objects except in the narrow list of safe ways is badness |
| 11:09 | <krijn> | annevk: heb jij mijn html5.org pass nog ergens? |
| 11:09 | <divya> | jgraham: likely they just square away opera with ie |
| 11:28 | <smaug____> | control.labels isn't live, right? |
| 11:54 | <zcorpan> | smaug____: why would it not be? |
| 11:58 | <smaug____> | zcorpan: I don't see anything in the spec saying it would be |
| 12:00 | <smaug____> | ah, by default it is live |
| 12:00 | <zcorpan> | smaug____: "Unless otherwise stated, a collection must be live." http://dom.spec.whatwg.org/#concept-collection |
| 12:00 | <smaug____> | readability is less than good |
| 12:20 | <MikeSmith_> | zcorpan: http://w3c-test.org/quirks-mode/ |
| 12:20 | <MikeSmith_> | sorry it took me so long to get around to it |
| 12:21 | <MikeSmith_> | looks like everything is there now as expected |
| 12:21 | <MikeSmith_> | http://w3c-test.org/quirks-mode/tests/ |
| 12:21 | <zcorpan> | MikeSmith_: thanks! |
| 12:21 | <MikeSmith_> | zcorpan: and now I'm trying to figure out how I can get the redirect set up on test.w3.org |
| 12:22 | <zcorpan> | MikeSmith_: cool |
| 12:25 | <annevk> | krijn: kan 'm resetten |
| 12:25 | <annevk> | krijn: doe ik nu even |
| 12:25 | <hsivonen> | oh great. Gecko detects BOMless UTF-16 for XML even though the spec says it’s prohibited |
| 12:25 | <hsivonen> | I wonder what kind of YSoD doom would ensue if I fixed that |
| 12:26 | <annevk> | krijn: wil je ftp houden of liever ssh? |
| 12:28 | <annevk> | noticing encoding issues on that w3c-test.org/quirks-mode URL |
| 12:29 | <hsivonen> | annevk: btw, the .txt files for the Encoding Standard need charset=UTF-8 (or BOM) |
| 12:30 | <zcorpan> | hsivonen: does the html spec support bomless utf-16 for html? last i checked i couldn't find anything |
| 12:31 | <hsivonen> | zcorpan: it doesn’t (except potentially via the heuristic detector black box) |
| 12:31 | <zcorpan> | ok |
| 12:31 | <zcorpan> | do you know what the browser landscape looks like offhand? |
| 12:32 | <hsivonen> | I don’t |
| 12:32 | <annevk> | hsivonen: but the files seem to work fine? |
| 12:32 | <annevk> | ooh, only in Opera |
| 12:32 | <hsivonen> | Gecko tries to detect the case where the file is all-Basic Latin BOMless UTF-16 |
| 12:32 | <hsivonen> | probably an overreaction |
| 12:32 | <zcorpan> | hsivonen: before fixing gecko to match the xml spec, might be worth it to see what happens in other browsers and in html. maybe the xml spec is just wrong? |
| 12:33 | <hsivonen> | if we reacted like that to Microdata, we’d have nuked the Microdata API by now |
| 12:33 | <hsivonen> | zcorpan: yeah. testing other browsers is just more annoying than looking at the Gecko code |
| 12:35 | <zcorpan> | annevk: opera detects utf-8. maybe we should drop that |
| 12:35 | <hsivonen> | in other news, Gecko looks broken in the case where the BOM or the XML declaration isn’t fully within the first network buffer |
| 12:35 | <annevk> | got some very bad latency over ssh :/ |
| 12:36 | <hsivonen> | Same thing with the CSS parser, it looks like, unless I’m missing some buffering |
| 12:36 | <hsivonen> | looks like I’m the only one in the habit of making my BOM sniffing resilient against buffer boundaries |
| 12:37 | <annevk> | hsivonen: I think I fixed it by adding AddDefaultCharset utf-8 |
| 12:38 | <annevk> | whoa, AddDefaultCharset defaults to iso-8859-1 |
| 12:38 | <hsivonen> | annevk: thanks |
| 12:39 | <hsivonen> | annevk: IIRC, Gecko works around that Apache stubbornness |
| 12:39 | <annevk> | zcorpan: it's causing breakage in other browsers! |
| 12:42 | <odinho> | annevk: mosh -- just installed it on client and server because I've been doing lots'a 3G lately. It makes remote ssh-ing smooth. :-) |
| 12:44 | <MikeSmith_> | zcorpan: OK set up http://test.w3.org/* to 301 to http://w3c-test.org/* |
| 12:44 | <zcorpan> | MikeSmith_: thanks. seems the redirect prepends a slash to the new url |
| 12:44 | <zcorpan> | in the path |
| 12:45 | <MikeSmith_> | yeah saw that I dunno why |
| 12:45 | <zcorpan> | how did you implement it? |
| 12:45 | <MikeSmith_> | RedirectMatch permanent ^(.*)$ http://w3c-test.org/$1 |
| 12:45 | <zcorpan> | I'd do: Redirect 301 / http://w3c-test.org/ |
| 12:46 | <zcorpan> | but otherwise dropping the slash before $1 would work i guess |
| 12:46 | <MikeSmith_> | ok lemme try that |
| 12:46 | <MikeSmith_> | ah yeah |
| 12:47 | <MikeSmith_> | OK slash shoudl be gone now |
| 12:48 | <zcorpan> | thanks! |
| 12:48 | <zcorpan> | MikeSmith_: i had sent an email about this (and the other redirect issue) http://www.w3.org/mid/op.wmdajyzjidj3kv⊙sl |
| 12:49 | <MikeSmith_> | yeah saw that |
| 12:49 | <MikeSmith_> | plh pinged me about it |
| 12:50 | <MikeSmith_> | hmm the link in that spec is still busted |
| 12:51 | <MikeSmith_> | since the tests subdirectory is gone |
| 12:52 | <MikeSmith_> | seems it should just get redirected to http://w3c-test.org/webapps/XMLHttpRequest/tests/ now, right |
| 12:52 | <MikeSmith_> | ? |
| 12:52 | <MikeSmith_> | I think if you add a redirect in an .htaccess in the repo, that should work |
| 13:01 | <zcorpan> | i did that, it didn't work |
| 13:02 | <zcorpan> | http://dvcs.w3.org/hg/webapps/rev/f5791dfb4e7b |
| 13:02 | <MikeSmith_> | ok |
| 13:02 | <MikeSmith_> | lemme check |
| 13:03 | <zcorpan> | maybe redirects are not allowed except for the root .htaccess? dunno if apache has such a setting |
| 13:03 | <MikeSmith_> | ah |
| 13:03 | <MikeSmith_> | yeah, probably |
| 13:04 | <MikeSmith_> | AllowOptions setting |
| 13:07 | <hsivonen> | about:blank is defined to be UTF-8, right? |
| 13:09 | <jgraham> | http://tools.ietf.org/html/draft-holsten-about-uri-scheme-06 says so, at least |
| 13:12 | <hsivonen> | ok. thanks |
| 13:14 | <MikeSmith_> | zcorpan: if you change it to Redirect 301 /webapps/tests/XMLHttpRequest/info.htm http://w3c-test.org/webapps/XMLHttpRequest/tests/submissions/Opera/info.htm |
| 13:14 | <MikeSmith_> | that should work |
| 13:15 | <MikeSmith_> | absolute path |
| 13:28 | <annevk> | zcorpan: how do you feel about TypeError? |
| 13:29 | <zcorpan> | annevk: you mean using an enum? |
| 13:29 | <annevk> | no just throwing TypeError |
| 13:30 | <annevk> | as if it was an enum, basically |
| 13:30 | <zcorpan> | i guess that works |
| 13:30 | <annevk> | cool |
| 13:54 | <annevk> | i fixed the stream thingie too I think |
| 13:55 | <annevk> | it should prolly be done in a nicer way though, if someone sees a way to rewrite the conceptual interfaces that'd be great |
| 14:12 | <jgraham> | http://programmers.stackexchange.com/questions/168751/is-the-use-of-utf8-preferable-to-utf8-true |
| 14:23 | <annevk> | interesting answer |
| 14:31 | <zcorpan> | MikeSmith_: seems the redirect works now. thanks! |
| 14:32 | <MikeSmith_> | cool |
| 14:37 | <zcorpan> | how was it again, setting event handler idl attributes to non-functions means it gets set to null? |
| 14:51 | <annevk> | think so |
| 15:25 | <annevk> | zewt: optional might then make sense, not sure about nullable |
| 15:27 | <annevk> | but I guess making input optional makes sense |
| 16:25 | <krijn> | annevk: maakt niet uit, ftp is goed genoeg denk ik |
| 17:36 | <zcorpan> | annevk: did specification-data move? |
| 18:30 | <annevk> | zcorpan: yes |
| 18:30 | <annevk> | zcorpan: https://github.com/whatwg/xref |
| 18:35 | <zcorpan> | ok, thanks. cloned. |
| 18:37 | <annevk> | zcorpan: you want to be a team member? |
| 18:37 | <zcorpan> | does that give me write access? |
| 18:37 | <annevk> | yeah |
| 18:37 | <zcorpan> | sure |
| 18:37 | <annevk> | gives you access to all things WHATWG on GitHub |
| 18:37 | <annevk> | simonp is you? |
| 18:37 | <zcorpan> | no |
| 18:38 | <zcorpan> | zcorpan |
| 18:38 | <annevk> | zcorpan: zcorpan gives a 500? |
| 18:38 | <zcorpan> | yeah i noticed |
| 18:39 | <zcorpan> | no idea why |
| 18:39 | <zcorpan> | i'm logged in as "zcorpan" |
| 18:39 | <annevk> | well you should have access now |
| 18:40 | <annevk> | zcorpan: I also pushed an update to Anolis so you can now reuse the same database for several specifications |
| 18:40 | <annevk> | zcorpan: all of the WHATWG standards have already been updated to that effect |
| 18:41 | <smaug____> | anyone know if there is js version of Graphviz' dot |
| 19:26 | <pablof> | is there a repo somewhere for the eventsource spec? |
| 19:46 | <Hixie_> | pablof: svn.whatwg.org, it's just part of HTML |
| 19:47 | <pablof> | thanks |
| 19:58 | <JonathanNeal> | In the Media Query language, if we're matching anything 30em we use (width: 30em), and if we're matching anything 30em or smaller we use (max-width: 30em), but what if we're matching anything less than 30em? |
| 20:00 | <Philip`> | (max-width: 29.999em) ? |
| 20:02 | <JonathanNeal> | That's the work around, definitely. |
| 20:02 | <JonathanNeal> | Has anyone suggested language that targets "less than"? |
| 20:03 | <Hixie_> | what's the use case? |
| 20:03 | <Hixie_> | (www-style would be the appropriate forum for this discussion, btw) |
| 20:09 | <JonathanNeal> | is that an email group, Hixie_? |
| 20:09 | <JonathanNeal> | or rather, where is www-style? |
| 20:10 | <JonathanNeal> | Hixie_: the usecase is defining multiple breakpoints based on the same value. The problem is that defining anything 30em or smaller is easy, but defining anything less than 30em is hard, you end up appending all these 9's. |
| 20:11 | <annevk> | JonathanNeal: http://lists.w3.org/Archives/Public/www-style/ |
| 20:11 | <JonathanNeal> | @media (max-width: 30em) {} @media (min-width: 30.0001em) && (max-width: 60em) {} |
| 20:11 | <Hixie_> | JonathanNeal: what anne said (sorry, was afk) |
| 20:12 | <Hixie_> | JonathanNeal: i don't understand why you can't just do a series of max breakpoints |
| 20:12 | <Hixie_> | JonathanNeal: like, max 300px, max 600px, max 900px, anything above |
| 20:14 | <JonathanNeal> | because then i have to manage more offsets, between the unmq'd stylesheet and now each mq matching stylesheet after that. |
| 20:14 | <Hixie_> | come again? |
| 20:14 | <Hixie_> | i don't follow |
| 20:24 | <JonathanNeal> | Sorry, Hixie_, I think there should be something like < and > (albeit those symbols may conflict with X/HTML). I thought something may have been pitched. |
| 20:32 | <JonathanNeal> | Like @media (max-width: 30em) {} @media (gt-width: 30em) && (max-width: 50em) {} |
| 20:38 | <JonathanNeal> | alternatively, above-width, below-width, over-width, under-width. |
| 20:41 | <JonathanNeal> | I like above and below because they have the name number of letters and fit nicely beside max and min. |
| 21:53 | SamB_MacG5 | wishes file:// had a CORS-equivalent ... |
| 23:34 | Hixie_ | deals with some feedback on the spec that makes him think he should require that everyone who comments on the spec should first read the spec and take a test |
| 23:34 | <Hixie_> | (though actually, the number of times people suggest something that hte spec already says is remarkably low, all things considered) |
| 23:49 | <SamB_MacG5> | Hixie_: that wouldn't be a good plan for clarification suggestions ... |
| 23:49 | <SamB_MacG5> | /requests |