| 00:29 | <MikeSmith> | Hixie: fwiw, I'd vote for dropping the term "xhtml document" altogether |
| 00:34 | <MikeSmith> | Hixie: if you need an alternative, consider "document in the XHTML syntax" |
| 00:35 | <MikeSmith> | or "conforming document in the XHTML syntax" or "document conforming to the XHTML syntax" |
| 00:52 | <Hixie> | hober: gotta represent! |
| 00:52 | <Hixie> | MikeSmith: i think hsivonen convinced me we should give the term lip service |
| 00:59 | <MikeSmith> | Hixie: OK |
| 01:05 | <Hixie> | i just looked up "complicated" in the thesaurus to find a better word to use somewhere in the spec and wow, that's just a long list of words to describe HTML |
| 01:05 | <paul_irish> | :D |
| 01:05 | <MikeSmith> | byzantine? |
| 01:05 | <MikeSmith> | baroque? |
| 01:06 | <Hixie> | intricate... bewildering... perplexing... labrynthine... tortuous... |
| 01:06 | <Hixie> | tricky... knotty... thorny... tangled... |
| 01:06 | <MikeSmith> | intertwingly |
| 01:08 | <Hixie> | in other news |
| 01:08 | <Hixie> | turns out i'd never specced how input.width and input.height actually worked |
| 01:08 | <Hixie> | they were hyperlinked to a section that described a bunch of other width and height IDL attributes, but didn't list <input> |
| 01:08 | <Hixie> | so, oops |
| 01:09 | <Hixie> | how the blazes am i supposed to test http://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 |
| 01:17 | <jgraham> | Hixie: That's what you get for using the word "just" before "build one" :p |
| 01:18 | <Hixie> | :-) |
| 01:20 | <jgraham> | But, uh, doesn't OSX use NFD for filenames? So test what browsers on OSX do with a filename that could contain a decomposed character, maybe? |
| 01:36 | <Hixie> | http://damowmow.com/playground/demos/filename-upload/ leads me to be even more confused |
| 01:37 | <Hixie> | some used 0xCC 0x88 and some used 0xC3 0xBC |
| 01:38 | <Hixie> | oh sorry |
| 01:38 | <Hixie> | some used u 0xCC 0x88 and some used 0xC3 0xBC. that makes more sense. |
| 01:55 | <jarek> | Hi |
| 01:55 | <jarek> | the DOM3 spec has following line: |
| 01:55 | <jarek> | "Authors should use the KeyboardEvent.char and KeyboardEvent.key attributes instead of the charCode and keyCode attributes, respectively." |
| 01:56 | <jarek> | is this really what developers should do currently? KeyboardEvent.char and KeyboardEvent.key does not seem to be supported by latest version of Chrome |
| 01:56 | <jarek> | s/does/do |
| 01:56 | <jgraham> | DOM3 events? |
| 01:56 | <jarek> | yeah |
| 01:57 | <jgraham> | That spec is not noted for being useful |
| 01:57 | <zewt> | did you cut out the "... if they don't want anything to work" part |
| 01:58 | <jarek> | uhm... let me check :) |
| 01:58 | <jgraham> | jarek: Anyway, you are all good per RFC2119 |
| 01:59 | <jarek> | yeah, it says something between those lines... |
| 02:00 | <jarek> | I was worried because it called keyCode and charCode as legacy |
| 02:06 | <jamesr_> | dom3 events can't really call anything else legacy |
| 02:06 | <jarek> | jamesr_: http://www.w3.org/TR/DOM-Level-3-Events/#legacy-key-attributes |
| 02:12 | <jgraham> | Seeriously, I wouldn't expect DOM3 events to be accurate |
| 02:15 | <jamesr_> | jarek, what i meant is that dom3 events is so old and incorrect you should ignore it |
| 02:15 | <jgraham> | d3e isn't old |
| 02:15 | <jamesr_> | jarek, what i meant is that dom3 events is so old and incorrect you should ignore it |
| 02:15 | <jamesr_> | sorry, mistaken |
| 02:15 | <jamesr_> | jgraham, well it has many old parts |
| 02:16 | <jamesr_> | some parts are newly edited |
| 02:16 | <jgraham> | Yes |
| 02:16 | <jamesr_> | many important parts are not |
| 02:16 | <jamesr_> | and it's a total mystery to me why anyone bothers editing it |
| 02:17 | <jarek> | is there any other specification that would describe keyboard events? |
| 02:17 | <jarek> | afair there was something on touch events |
| 02:18 | <jarek> | but that's different story |
| 02:19 | <jarek> | http://www.w3.org/TR/touch-events/ |
| 02:20 | <jarek> | ^ why it is not part of DOM3 events? |
| 02:20 | <jarek> | is it going to be merged in the future? |
| 02:39 | <wycats> | Hixie: above I asked why the new form validation events don't bubble |
| 03:04 | <kennyluck> | (ask again) Is there any problem if browsers ignore media type of a manifest? I think this was probably discussed to death but I would be grateful if someone reminds me again. |
| 03:16 | <Hixie> | wycats: in case the form control is in a form that isn't the form it's associated with |
| 03:16 | <Hixie> | kennyluck: well it would violate the HTTP spec... |
| 03:16 | <wycats> | Hixie: it basically breaks event delegation though |
| 03:16 | <wycats> | event delegation is a pretty standard way to build apps |
| 03:20 | <Hixie> | event delegation? |
| 03:24 | <wycats> | Hixie: it's common for people to register for events in entire regions of the page |
| 03:24 | <wycats> | and use event.target to identify where the event came from |
| 03:24 | <wycats> | this has two positive effects |
| 03:24 | <wycats> | 1) no need to register handlers for all elements you are interested in (performance) |
| 03:25 | <wycats> | 2) ability to dynamically generate markup without having to worry about also binding events |
| 03:25 | <wycats> | http://api.jquery.com/delegate/ jQuery provides widely-used facilities for this |
| 03:25 | <Hixie> | sure |
| 03:25 | <Hixie> | you can still do that |
| 03:25 | <Hixie> | just register a capture listener on whatever element you want to do it on |
| 03:27 | <wycats> | Hixie: almost no existing delegation facilities use capture |
| 03:27 | <wycats> | and further, capture has the reverse intended effect |
| 03:28 | <wycats> | namely, it bubbles backwards from the expected direction |
| 03:29 | <Hixie> | if all you want to do is delegate, it doesn't matter what direction it goes in |
| 03:33 | <wycats> | Hixie: it matters if you want to avoid conflicting with event handlers that some other code may have registered |
| 03:33 | <Hixie> | i don't really understand the use case here |
| 03:33 | <Hixie> | but you can always work around it by adding a capture handler on the root that refires the event as a bubbling event :-) |
| 03:36 | <wycats> | refiring isn't particularly reliable, especially with events with native handling |
| 03:36 | <wycats> | Hixie: trust me when I say "events that don't bubble are broken to most developers" |
| 03:36 | <wycats> | https://groups.google.com/forum/#!topic/jquery-standards/SKdrgth7igY |
| 03:41 | <kennyluck> | Hixie, can you elaborate on this a little bit? (re. it would violate the HTTP spec) Is that a strong reason given how many times "willful violation" appears in the spec? |
| 05:04 | <Hixie> | wycats: i don't see why refiring wouldn't work if you really needed it |
| 05:04 | <Hixie> | wycats: bubbling would be broken too, for this particular feature |
| 05:04 | <Hixie> | wycats: if there are specific uses cases you want me to look at, though, that might show that i am wrong, which would be useful |
| 05:04 | <Hixie> | wycats: it's hard to discuss in the abstract |
| 05:05 | <Hixie> | kennyluck: the wilful violations are all because i had no choice, e.g. because the other spec contradicts reality |
| 05:49 | <roc> | I have an interesting spec philosophy question |
| 05:51 | <heycam> | choice of font? |
| 05:51 | <roc> | yeah right |
| 05:51 | <roc> | I have an API that lets a Worker generate data for a MediaStream. This is done by periodically firing an event at the Worker to fetch more data. Suppose the MediaStream isn't connected to anything and is eventually GCed. |
| 05:52 | <roc> | Should I keep firing events at the Worker to preserve the non-observability of GC? |
| 05:52 | <roc> | (Which means, of course, keeping the Worker alive) |
| 05:52 | <heycam> | hmm, well are you required to fire the event at any particular rate? |
| 05:52 | <heycam> | can the worker tell that the worker should have fired an event by a particular time? |
| 05:53 | <roc> | not really |
| 05:53 | <roc> | but I think it'd be reasonable to expect the event to fire *eventually* |
| 05:54 | <heycam> | yeah. is it just theoretical observability that you're worried about? or practical web compat problems due to different gc strategies? |
| 05:54 | <jgraham> | I don't understand what events would be fired once the stream wasn't connected to anything |
| 05:54 | <roc> | conceptually the stream keeps playing, but no-one's listening |
| 05:55 | <roc> | I haven't thought about Web compat problems |
| 05:55 | <heycam> | i know: kill the worker, then it won't know a thing ;) |
| 05:55 | <roc> | I have written a test that accidentally broke because the stream got GCed and my worker stopped getting called, and I was waiting for it to get through a certain amount of work |
| 05:55 | <zewt> | fwiw you could get the same effect (logically) without workers complicating the question, if you were firing progress events on a stream and the same thing happened |
| 05:55 | <jgraham> | Can't you make that explicit? |
| 05:56 | <roc> | make what explicit? |
| 05:56 | <zewt> | (on an abstract stream--not talking about any particular API, not sure if there are any that fit) |
| 05:57 | <roc> | one possibility I just thought of is that I could try making MediaStreams that aren't connected to anything block |
| 05:58 | <roc> | then if a MediaStream gets GCed, it must have been blocked, in which case it's correct to stop firing processmedia events at the worker |
| 05:58 | <zewt> | i don't know that API, but that seems better than requesting info and throwing it away if nobody's connected to it; that just seems wasteful |
| 06:00 | <roc> | but that means if you want a ProcessedMediaStream whose worker just analyzes input samples and doesn't produce anything, you'll need to nevertheless connect it to a dummy muted audio element :-( |
| 06:00 | <zewt> | from an I/O-pin-based API perspective that's not too horrible |
| 06:02 | <jgraham> | roc: That sounds OK to me. Conceptually having no low if there is no sink sounds reasonable |
| 06:02 | <jgraham> | *flow |
| 06:02 | <roc> | hmm ho |
| 06:03 | <zewt> | out of curiosity, if you start a chain like that, and drop all references to the objects, is there any way to get it back (eg. a "array of currently playing streams" attribute somewhere), or is it effectively leaked and playing forever? |
| 06:04 | <zewt> | (leaking like that isn't too bad--don't do that--but a little unusual on the platform) |
| 06:04 | <zewt> | (of course, you can't say "the input element gets GC'd and it stops", since then you're back at square one with exposed GC behavior :) |
| 06:05 | <roc> | in this API I use media elements for output |
| 06:06 | <roc> | and media elements already handle this issue |
| 06:06 | <roc> | basically you can go (new Audio(...)).play(); |
| 06:06 | <roc> | dropping the reference to the element |
| 06:06 | <roc> | and it will play until the stream ends |
| 06:06 | <roc> | and then everything gets cleaned up |
| 06:06 | <roc> | of course, the stream might not end, but whatever |
| 06:07 | <roc> | also, if the document becomes "inactive" (which is very carefully defined), the element pauses automatically, and since there's no reference to it there's no way to start it again so again we can clean up |
| 06:08 | <roc> | jgraham: thanks for the reassurance, I'll probably go that way :-) |
| 06:16 | <wycats> | Hixie: can you explain the use-case for it not bubbling better? |
| 06:24 | <Hixie> | wycats: if someone were to use the fact that it bubbled to put a handler on a <form>, that handler would fire even for controls that were children of the form but had a form="" attribute and were thus associated with another form. |
| 06:25 | <wycats> | them's the breaks with bubbling in general |
| 06:25 | <wycats> | we could fire a different event on associated forms |
| 06:25 | <wycats> | invalidform |
| 06:25 | <Hixie> | or we could just not bubble, since there doesn't seem to be a use case for it :-) |
| 06:26 | <wycats> | Hixie: it's inconsistent |
| 06:26 | <wycats> | other events bubble |
| 06:26 | <Hixie> | not all of them |
| 06:27 | <wycats> | and look what jQuery does -- it creates bubbling versions of the non-bubbling events |
| 06:27 | <wycats> | nobody wants non-bubbling events |
| 06:27 | <Hixie> | clearly not nobody |
| 06:27 | <Hixie> | maybe jquery's authors don't |
| 06:27 | <wycats> | web authors don't :) |
| 06:27 | <Hixie> | some web authors do |
| 06:27 | <wycats> | which ones? |
| 06:27 | <Hixie> | me, for one |
| 06:28 | <wycats> | Hixie: the fact that focus doesn't bubble, for instance, is the source of considerable pain |
| 06:29 | <Hixie> | and if 'invalid' were to bubble, _that_ would cause pain |
| 06:29 | <hsivonen> | I wonder what would be the most effective way to get the person implementing HTML parsing in IE take a look at http://hsivonen.iki.fi/test/moz/bug696651-1.html and compare with Gecko/WebKit/Ragnarök |
| 06:29 | <wycats> | Hixie: in the case where people use form="..."? |
| 06:29 | <Hixie> | wycats: yup |
| 06:30 | <Hixie> | wycats: what's the use case for looking at the 'invalid' event anywhere but the control? |
| 06:30 | <wycats> | Hixie: using the standard event delegation infrastructure that people use for every other event |
| 06:30 | <Hixie> | hsivonen: is that related to a potential spec change? |
| 06:30 | <hsivonen> | Hixie: AFAIK, no |
| 06:30 | <Hixie> | wycats: that's not a use case, that's a bunch of buzzwords. |
| 06:30 | <Hixie> | hsivonen: thank god. |
| 06:30 | <Hixie> | hsivonen: that test case looks scary. |
| 06:30 | <hsivonen> | Hixie: rather, it seems to me IE is failing to follow the spec |
| 06:30 | <Hixie> | hsivonen: i was worried i might have to understand it. :-P |
| 06:30 | <wycats> | Hixie: "event delegation" how is that a buzzword? |
| 06:31 | <wycats> | what you're saying is that people should build their own event delegation specifically for the invalid event |
| 06:31 | <wycats> | using capture |
| 06:31 | <wycats> | which isn't available in all browsers, so it would fail on polyfills |
| 06:31 | <Hixie> | wycats: no, i'm saying that there hasn't been any description of a use case for event delegation for the 'invalid' event on form controls |
| 06:32 | <wycats> | Hixie: I explained above why people want event delegation - it's to make it easy to dynamically insert markup without having to worry about also binding events |
| 06:32 | <Hixie> | wycats: that makes no sense for a form control's invalid event |
| 06:32 | <Hixie> | wycats: the whole point of that event is to do different things for each control |
| 06:33 | <wycats> | the point of event delegation libraries is to have an event that behaves as-if it was bound directly, but without having to bind it |
| 06:34 | <wycats> | $(document).delegate("input.something", function() { /* handle invalid events for elements with "something" class here */ }) |
| 06:35 | <Hixie> | show me a use case for giving multiple controls the same oninvalid handler |
| 06:35 | <wycats> | one moment please |
| 06:39 | <wycats> | what, in your mind, is the use case for the invalid event on individual elements |
| 06:40 | <hsivonen> | maybe I should submit the test I mentioned above to html5lib test suite (in one of the scripted tree builder test files) |
| 06:43 | <zewt> | Hixie: the "dynamic elements" case doesn't need multiple controls with the same behavior, fwiw |
| 06:43 | hsivonen | sighs at av_param. |
| 06:43 | <hsivonen> | looks like I will have to write a counter change proposal if that one is submitted to the WG |
| 06:43 | <hsivonen> | or was it submitted already? |
| 06:44 | <zewt> | not very familiar with form validation just yet, but i could easily see the same "invalid data" behavior for eg. multiple phone numbers (work, home, mobile) in the same form ("awooga, bad phone number") |
| 06:44 | <hsivonen> | Risks: None identified |
| 06:44 | <wycats> | Hixie: I'm honestly at a loss for how to explain this to you -- do you understand that you may find that you want the same behavior on the case of invalidity in several places on a page? and that you might now want all of the annotated elements to have to be present on that page when you initially register the handlers? |
| 06:44 | <zewt> | wycats: s/now/not/, presumably :) |
| 06:44 | <hsivonen> | right. as if I didn't identify a risk in the bug. :-( how hard would it have been to copy and paste it over? |
| 06:44 | <wycats> | Hixie: keeping in mind that you have access to the target element no matter where the event itself was bound |
| 06:45 | <hsivonen> | Negative Effects: None identified |
| 06:45 | <hsivonen> | Conformance Classes Changes: None identified |
| 06:45 | <hsivonen> | seriously? |
| 06:47 | <Hixie> | wycats: sorry, was afk |
| 06:47 | <Hixie> | wycats: pretty much the only use case is displaying very specialised error notifications, e.g. on a field with a complicated pattern, displaying a graphic showing the allowed pattern. |
| 06:48 | <wycats> | Hixie: you assume CSS will handle all other cases you care about? |
| 06:48 | <Hixie> | hsivonen: fwiw in the past when a decision has been made that browsers haven't wanted to implement, it's been dealt with quite quickly without much work from vendors |
| 06:49 | <Hixie> | wycats: no need for CSS even |
| 06:49 | <wycats> | Hixie: the invalid event allows you to customize the behavior / style of invalid elements - it's only irrelevant if CSS picks up all the remaining slack |
| 06:50 | <Hixie> | wycats: why would you style anything at all? just let the browser do it |
| 06:50 | <Hixie> | wycats: styling the error messages is like styling the form controls, it's bad ui |
| 06:50 | <Hixie> | wycats: just trust the browser to use platform conventions |
| 06:51 | <wycats> | I'm honestly at a loss; I'll compose an email |
| 06:51 | <wycats> | and let others chime in |
| 06:51 | <wycats> | :) |
| 06:51 | <Hixie> | e-mail and bugs are the only way changes are going to be made anyway :-) |
| 06:51 | <wycats> | Hixie: yep |
| 06:51 | <Hixie> | but make sure to give use cases |
| 06:51 | <Hixie> | that's pretty much all i look at |
| 06:52 | <Hixie> | (that and what the browsers are doing) |
| 06:52 | <wycats> | Hixie: I'm seriously baffled that you think that the entire problem of form validation and the related UI is now a solved problem |
| 06:52 | <wycats> | I would love for that to be true |
| 06:52 | <Hixie> | why would it not be true? |
| 06:52 | <Hixie> | (for common controls, that is) |
| 06:53 | <wycats> | because the semantics of what invalidity actually means can differ |
| 06:53 | <Hixie> | (obviously for complicated cases there are needs for scripted ui, but that's why we have oninvalid) |
| 06:53 | <wycats> | and I'll bet dollars to donuts that we didn't hit even close to every case |
| 06:53 | <Hixie> | can you possibly give a concrete example |
| 06:53 | <wycats> | Hixie: I will email the list |
| 06:53 | <Hixie> | make sure to include concrete examples and use cases |
| 06:53 | <wycats> | Hixie: no problem |
| 06:54 | <Hixie> | it's _some_ problem, i've been asking for them for over 30 minutes now without luck :-/ |
| 06:55 | <wycats> | I need to figure out how to articulate what you think are "buzzwords" in a way that you will consider valid |
| 06:55 | <wycats> | so I will think about it and send an email |
| 06:56 | <Hixie> | a use case is something like "on this web page i'm writing at http://foobar.example.net/bla/quux.html, you'll notice there's an airline seat chart, and when the user clicks on the seat i fill in an input field, and..." etc |
| 06:56 | <Hixie> | referencing common development methodologies isn't a use case, however you phrase it |
| 06:56 | <Hixie> | it needs to be a real-world actual problem |
| 06:56 | <Hixie> | faced by a specific author and user |
| 06:58 | <wycats> | is the user allowed to be using popular libraries? |
| 06:58 | <wycats> | or are they required to be writing everything by hand using the raw DOM API? |
| 06:59 | <zewt> | use cases do not have to be real-world actual problems; realistic, theoretical uses are also use cases |
| 06:59 | <Hixie> | you mean the author? the user doesn't use libraries :-) |
| 06:59 | <zewt> | otherwise you'd never have any use cases for apis that don't exist yet, and you couldn't create any new apis :) |
| 07:00 | <wycats> | Hixie: yes, the author |
| 07:00 | <Hixie> | wycats: doesn't matter, doesn't affect the use case |
| 07:01 | <wycats> | Hixie: so as long as the author can solve their problem without libraries, it's invalid? |
| 07:01 | <Hixie> | wycats: author = author code + library code |
| 07:02 | <Hixie> | wycats: (abviously any problem that can be solved with libraries can be solved without libraries) |
| 07:02 | <wycats> | Hixie: yes that is true mathematically |
| 07:03 | <Hixie> | wycats: if you mean "is a problem caused by a library a valid problem", the answer is obviously no, since it's far easier to fix the library than every browser |
| 07:03 | <wycats> | I'm not sure why common development techniques for working with events are irrelevant |
| 07:03 | <wycats> | Hixie: it's a new event |
| 07:03 | <wycats> | and it may not be easy to fix libraries, if you're asking them to deviate from their standard practice for one specific event |
| 07:04 | <wycats> | Hixie: my point is purely that people use bubbling to bind events to elements that don't exist yet, based on some annotation on the element |
| 07:04 | <wycats> | your point is that the invalid event is largely useless anyway |
| 07:04 | <Hixie> | honestly i don't see much point in using a library to hook an event, unless it's to work around browser differences |
| 07:04 | <Hixie> | it's not like dom events is a difficult api to use |
| 07:04 | <wycats> | Hixie: you're trolling me right? |
| 07:04 | <Hixie> | no? |
| 07:05 | <wycats> | Hixie: let's get drinks with Alex Russell and discuss this some time |
| 07:05 | <Hixie> | if you were talking about indexeddb that would be different |
| 07:05 | <Hixie> | alex and i have rather different views of how the web should work |
| 07:05 | <wycats> | Hixie: in your mind, users should type as much as possible and pass as many boolean flags as possible? |
| 07:05 | <Hixie> | ( and every time we talk about it, he convinces me further that he's wrong :-) ) |
| 07:05 | <Hixie> | users shouldn't type anything |
| 07:05 | <wycats> | authors |
| 07:06 | <Hixie> | not sure what you mean by "boolean flags" here |
| 07:06 | <wycats> | Ajax sync/async, capture/bubbling phase |
| 07:06 | <wycats> | APIs have mandatory boolean flags where 99.999% of usage is one or the other |
| 07:06 | <Hixie> | neither of those requires passing any boolean flags |
| 07:06 | <Hixie> | as the last argument to addEventListener() is optional |
| 07:06 | <Hixie> | and XMLHttpRequest defaults to async |
| 07:07 | <zewt> | wycats: i think you're getting distracted--not having to pass flags to a function isn't why delegation is useful (if that was all it was for, you'd just use a helper function) |
| 07:08 | <wycats> | zewt: I am in fact getting distracted |
| 07:10 | <wycats> | zewt: I'm just getting frustrated by the need to provide a use-case for event delegation being useful |
| 07:11 | <wycats> | I'm going to organize my thoughts and try to apply them clearly to the invalid event |
| 07:11 | <wycats> | and then send an email |
| 07:12 | <zewt> | wycats: by the way, there's no reason to frame use cases for delegation in terms of delegation |
| 07:13 | <zewt> | use cases for delegation are all really use cases for event bubbling, since delegation is just bubbling with some helpers wrapped around it |
| 07:13 | <zewt> | (so you can strip a layer of abstraction away from what you're talking about by putting that aside) |
| 07:15 | <wycats> | zewt: event delegation is bubbling that makes use of event.target |
| 07:15 | <wycats> | no? |
| 07:15 | <zewt> | yep |
| 07:15 | <wycats> | zewt: that's what I mean by "event delegation" |
| 07:15 | <zewt> | i know |
| 07:15 | <wycats> | I think without the target property, bubbling would in fact not be very useful here |
| 07:16 | <wycats> | if there is a case for direct binding, there defacto is a case for bubbling + target |
| 07:16 | <wycats> | but I need to figure out how to clearly explain that |
| 08:41 | <annevk> | foolip, I keep forgetting that Microdata has no relationship to the rest of the page |
| 08:42 | <annevk> | I wonder whether I'm the only one |
| 08:51 | <annevk> | foolip, your Live Microdata has a giant XSS hole |
| 08:51 | <annevk> | foolip, not sure if that's problematic for your site or not |
| 08:57 | <annevk> | Argh. DOM Level 3 Events also changes the way dispatchEvent() works from DOM Level 2 Events |
| 08:57 | <annevk> | And http://w3c-test.org/webapps/DOMEvents/tests/submissions/Microsoft/converted/dispatchEvent.NOT_SUPPORTED_ERR.html tests one of those new silly conditions... |
| 09:01 | <hsivonen> | annevk: the Microdata API encourages the kind of thinking that Microdata has a relationship to the DOM structure :-/ |
| 09:03 | <annevk> | So actually Hixie didn't think of it either when he made that new Microdata-inspired Atom example |
| 09:05 | <hsivonen> | aargh. http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Oct/0051.html |
| 09:05 | <Hixie> | annevk: which one? |
| 09:06 | <Hixie> | hsivonen: i'm sure he feels the same way in reverse :-) |
| 09:07 | <Hixie> | annevk: oh the pubdate thing |
| 09:07 | <Hixie> | annevk: interesting point |
| 09:07 | <annevk> | Hixie, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14202 |
| 09:07 | <annevk> | yeah |
| 09:07 | <annevk> | foolip spotted it |
| 09:07 | <annevk> | I had forgotten about it again |
| 09:08 | <zcorpan> | hsivonen: it makes perfect sense to use RDFa in XML Schema and XSLT |
| 09:11 | <Hixie> | annevk: i wonder what the use case is for pubdate. is it just a replacement for Atom, for syndication? |
| 09:12 | <Hixie> | annevk: if so, we can just also tell people to specify a "url" and make sure that the permalink is what is used |
| 09:12 | <Hixie> | annevk: and then say that syndicators should grab all the items of type Blog or whatever and then find their URLs and look those up and get the <article>s that they point to, or something |
| 09:14 | <zcorpan> | Hixie: r6773 - you can't bind Esc with accesskey |
| 09:14 | <Hixie> | not yet, no |
| 09:14 | <zcorpan> | so the example is confusing because it implies that you can |
| 09:17 | <annevk> | Hixie, I don't know really; I just thought Microdata might be a nice way to solve this rather niche case but then it turns out I don't understand Microdata... |
| 09:18 | <Hixie> | zcorpan: can you think of another example that would have a different last symbol in windows and mac that _is_ possible with the first version of this new accesskey? |
| 09:19 | <zcorpan> | no |
| 09:19 | <FlorianX> | could someone tell me when the canvas was integrated into html5? Thanks |
| 09:19 | <Hixie> | 2007? around when safari first came out with it. |
| 09:20 | <zcorpan> | http://www.whatwg.org/specs/web-apps/2005-09-01/#dynamic |
| 09:20 | <FlorianX> | Hixie: thank this limited the search in your commits :-) |
| 09:21 | <FlorianX> | zcorpan: Thanks! |
| 09:21 | <zcorpan> | 2005 there was no svn |
| 09:21 | <Hixie> | 2005, wow |
| 09:21 | <Hixie> | canvas has been in the spec longer than the w3c had existed by the time it decided html was dead |
| 09:22 | <FlorianX> | ok thanks |
| 09:22 | <Hixie> | ok i really have to go to bed |
| 09:22 | <Hixie> | nn |
| 09:22 | <FlorianX> | gn8 |
| 10:20 | <Margle> | what's the objective of this channel? |
| 10:22 | <annevk> | allow people to communicate? |
| 10:24 | <Margle> | to what end? |
| 10:26 | <annevk> | creating standards typically |
| 10:30 | <Margle> | I've reached the beginning? |
| 10:34 | <abarth> | Margle: its a loop. there is no beginning |
| 10:37 | <Margle> | and thus: standards immatate time. |
| 10:37 | <abarth> | well, time is a cube |
| 10:37 | <Margle> | abarth: and standards are a donut? |
| 10:45 | <zcorpan> | Margle: no. standards suck |
| 10:45 | <abarth> | what ever happened to standards suck? |
| 10:45 | <abarth> | maybe there will be new ones after TPAC? |
| 10:46 | <Margle> | ok |
| 10:46 | <Margle> | so… why does everyone come here to talk about stuff that sucks? |
| 10:47 | <Margle> | can't be just talk about other stuff? |
| 10:47 | <zcorpan> | seems like it hasn't been active in two years |
| 10:47 | <annevk> | tried making one with hasather but that really didn't go anywhere |
| 10:48 | <zcorpan> | you should interview abarth :) |
| 10:49 | <zcorpan> | "can you explain how web security works in three sentences?" |
| 10:49 | <abarth> | it doesn't |
| 10:49 | <abarth> | (sort interview) |
| 10:49 | <abarth> | short |
| 10:49 | <annevk> | :) |
| 11:34 | <hasather> | The classList methods would be more useful if they took a space separated list of class names |
| 11:36 | <zcorpan> | hasather: file a bug |
| 11:37 | <hasather> | zcorpan: yea |
| 11:47 | <karlcow> | http://raven.io/ |
| 12:30 | <asmodai> | awesome, logos in CSS: http://www.ecsspert.com/twitter.php |
| 12:30 | <asmodai> | Pity the site references w3schools though :( |
| 14:30 | <foolip> | nessy, I'm making some tweaks to http://www.w3.org/html/wg/wiki/ChangeProposals/issue-179_no_change |
| 14:30 | <nessy> | oh, I am still working on it |
| 14:30 | <nessy> | give me about 10 min |
| 14:31 | <foolip> | ok, will do |
| 14:42 | <nessy> | ok, it's still a bit raw, but I am grateful you want to chip in |
| 14:42 | <nessy> | go for it :-) |
| 14:49 | <foolip> | ok, I just changed the formatting a bit, it was way too wide for me |
| 14:59 | <nessy> | ah, oops |
| 15:02 | <foolip> | nessy, do you know what the appropriate way of entering complaints about the original proposal is? |
| 15:03 | <foolip> | for example, I want to complain that it doesn't have any implementation details, but under which section of the counter proposal does that belong? |
| 15:11 | <nessy> | I don't know either |
| 15:11 | <nessy> | I thought I'd put it under "Details", but that's really for proposing what to enter into the spec |
| 15:12 | <nessy> | http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal <- doesn't really describe what a counter change proposal should include |
| 15:13 | <nessy> | looking at this http://www.w3.org/html/wg/wiki/ChangeProposals/KeepMicrodata it seems the "Rationale" section needs to contain the details |
| 15:14 | <nessy> | let's remove the "Details" header then |
| 15:14 | <nessy> | are you editing? |
| 15:16 | <foolip> | not right now |
| 15:16 | <foolip> | I'm done for today I think, but I'm monitoring it and might throw and some stuff if you don't object |
| 15:17 | <foolip> | uh |
| 15:17 | <foolip> | throw in, as in add, not throw as in remove :) |
| 15:18 | <nessy> | sure |
| 15:18 | <nessy> | I am about to go to bed, so will likely not edit anything in about 15 hours (have to take my son to Basketball in the morning) |
| 15:21 | <foolip> | have a nice weekend, then :) |
| 15:23 | <nessy> | thanks :-) you, too |
| 15:23 | <nessy> | I'll monitor the situation :-) |
| 15:23 | <nessy> | nn |
| 15:28 | <zewt> | ... g+ seriously doesn't do rss? what? |
| 15:56 | <karlcow> | zewt: ... seriously why using g+? what? |
| 16:03 | <zewt> | ... i'm not? |
| 16:31 | <bfrohs> | Has there been any suggestions for a relative tabindex based on the current section? For example, a form that you know what order you want each field to be selected, but you don't know the placement on the actual page? |
| 16:32 | <bfrohs> | Code example: http://bit.ly/vxrjt5 -- obviously with a different attribute or format for doing it relatively instead |
| 16:37 | <AryehGregor> | I haven't heard such suggestions, but it would make sense. |
| 16:39 | <bfrohs> | It's been the one thing I never liked about tabindex (and the only reason I almost never use it). Because, quite frankly, websites are built in sections. Back when every page was simple and linear, the tabindex the way it is made sense (to an extent), but with websites nowadays, there needs to at least be an option for relative tabindex. |
| 16:42 | <bfrohs> | And I believe it may be good enough to simply rely on the outline algorithm, but some may want it to take into account fieldsets and the like as well. |
| 16:43 | <AryehGregor> | Or have an attribute like accesskeyscope, similar to itemscope and undoscope, which indicates that all descendants' accesskeys are to be interpreted as relative. |
| 16:52 | <bfrohs> | Well, in a limited way, that could work. But that makes it impossible to mark an item with an absolute tabindex. |
| 16:53 | <AryehGregor> | Why would you want to mix relative and absolute in the same subtree? We don't have to satisfy all use-cases if that will make things more complicated. |
| 16:53 | <AryehGregor> | If you want to do fancy stuff, you can always work out absolute tabindexes. |
| 16:53 | <bfrohs> | Also, if you had two forms, both of which you wanted to have relative tabindexes, but the second form to be accessed first, you would be limited there as well. |
| 16:53 | <bfrohs> | Oh, just thinking up all use-cases cause my mind is terrible like that. |
| 16:54 | <bfrohs> | But honestly, for my needs, accesskeyscope would be more than enough |
| 16:54 | <annevk> | tabindexscope, no? |
| 16:54 | <bfrohs> | well, yeah, just using the attribute AryehGregor provided |
| 16:55 | <AryehGregor> | I misspoke, obviously. |
| 16:56 | <bfrohs> | The only issue with tabindexscope (and piggybacking off of tabindex) is backward compatibility with older browsers. Get two or more forms on the same page using tabindexscope, and it makes it a huge pain to fill out a form using tab. |
| 16:57 | <bfrohs> | (tab goes to first field in second form, instead of second in first) |
| 16:57 | <AryehGregor> | True. |
| 16:58 | <bfrohs> | So, even if everyone was using an updated browser, we would have to wait until every major browser supported it before it could be used (and not piss off a lot of other people). |
| 16:59 | <bfrohs> | And that's in a perfect world. Can't imagine how it would work in this world ;) |
| 16:59 | <AryehGregor> | It doesn't seem worth it, really. |
| 17:02 | <annevk> | especially since keyboards are sort of moving away from being the dominant way to browse the web |
| 17:02 | <zewt> | ehh |
| 17:03 | <bfrohs> | Yes, but someday we may talk to our websites. "Next field" for example |
| 17:03 | <zewt> | the existance of other input methods does not mean it's okay to ignore keyboard accessibility as if keyboards are somehow going away |
| 17:04 | <zewt> | bfrohs: mobile browsers already use "next field" during form inputs, btw |
| 17:04 | <annevk> | wow, way to go from does not seem worth it to optimize for to ignore them altogether |
| 17:04 | <zewt> | ... |
| 17:05 | <zewt> | you suggested that improvements should not be made to keyboard navigation [because of touchscreens], which is a terrible idea |
| 17:06 | <zewt> | improvements -> this improvement |
| 17:07 | <annevk> | this is not an even an improvement to keyboard navigation |
| 17:07 | <annevk> | it's an improvement to authoring for it, but whatever |
| 17:07 | <zewt> | same thing, IMO |
| 17:07 | <bfrohs> | Well, in a way, it is an improvement. Because, right now, people rarely do tabindex on more than one form. |
| 17:07 | <bfrohs> | If they do it for one at all |
| 17:08 | <bfrohs> | Example: Facebook has it for their log in form. They don't use it for any other form on their site that I can find. |
| 17:27 | <annevk> | oh, Apple is "only" charging EUR 700 |
| 17:30 | <michel_v> | as for touchscreens, tabindex might still be useful to consider when some browsers (Safari on iOS comes to mind) do have "previous field / next field" buttons when filling forms |
| 17:31 | <zewt> | <zewt> bfrohs: mobile browsers already use "next field" during form inputs, btw <- :) |
| 17:32 | <michel_v> | oh, sorry. missed that line while reading the backlog |
| 17:39 | <bfrohs> | With these touchscreen/mobile/keyboard-is-dead arguments, should 'tabindex' be rethought entirely with the knowledge we now have of some of the new technologies that have come out (and will come out)? Because tabindexscope is only to fix the 'documents are no longer basic and linear' problem. Would there be another solution that would be better suited for touchscreens/non-keyboard-based-technologies? |
| 17:49 | <karlcow> | bfrohs: for inspiration there might be things to check into http://www.w3.org/standards/techs/multimodal#w3c_all |
| 17:50 | <annevk> | bfrohs, I actually think CSS is probably the better place to put these kind of things |
| 17:51 | <annevk> | bfrohs, the UI module has nav-index and some similar properties already |
| 17:51 | <annevk> | bfrohs: if you tie it markup it might not make sense if you apply a different style sheet that reorders some controls |
| 17:51 | <MikeSmith> | karlcow: I'm not inspired by that page |
| 17:52 | <karlcow> | :D |
| 17:52 | karlcow | will inspire MikeSmith in a few days |
| 17:57 | <karlcow> | http://www.w3.org/wiki/MeetingTaxis#Arrivals |
| 18:03 | <annevk> | oh interesting |
| 18:04 | <annevk> | I arrive an hour before you and dom |
| 18:04 | <Rik`> | btw, have you noted that there is a summer time change those weeks? |
| 18:06 | <AryehGregor> | jgraham, did you ever review the assert_throws patch I posted here? |
| 18:06 | <AryehGregor> | (we really need to set up a better patch review system than me pastebinning stuff and pinging you on IRC) |
| 18:06 | <MikeSmith> | you guys should share a taxi |
| 18:06 | <MikeSmith> | costed about $100 for a taxi I took last night |
| 18:06 | <MikeSmith> | which is nuts |
| 18:06 | <MikeSmith> | they have this thing of charging 150% over what the meter shows |
| 18:06 | <MikeSmith> | if the trip is farther than 15 miles |
| 18:06 | <MikeSmith> | btw, on http://platform.html5.org/, should I just change "DOM4" to "DOM"? |
| 18:06 | <MikeSmith> | and still link to the DOM4 spec of course |
| 18:07 | <MikeSmith> | annevk: ↑ |
| 18:08 | <bfrohs> | annevk, nav-index has the same problem as tabindex in that it is absolute. If there was a nav-index-scope, AND counter() could be used as the value for nav-index, then it would be sufficient. |
| 18:09 | <annevk> | MikeSmith, yeah |
| 18:11 | <bfrohs> | (where nav-index-scope was 'absolute' (or inherit) by default, with 'absolute' or 'relative' as values) |
| 18:12 | <MikeSmith> | annevk, OK, done |
| 18:15 | <karlcow> | annevk: I'm adding you the mail I'm sending to dom |
| 18:16 | <bfrohs> | Where would be the best place to suggest adding nav-index-scope to css ui? And making sure counter() values can be used for nav-index? |
| 18:16 | <karlcow> | rha my mail is in French :D |
| 18:16 | <karlcow> | retranslating in English |
| 18:22 | <karlcow> | annevk: mail sent. |
| 18:23 | <annevk> | thanks |
| 18:24 | <karlcow> | my pleasure |
| 18:24 | karlcow | is out |
| 18:25 | <AryehGregor> | annevk, what's the procedure for updating DOM4? Should I just push to both dvcs.w3.org and bitbucket.org? |
| 18:30 | <annevk> | yeah |
| 18:30 | <AryehGregor> | Okay. |
| 18:35 | <AryehGregor> | Should isPointInRange() throw IndexSizeError if the offset is too large or negative, or should it return false? WebKit throws, Gecko returns false. |
| 18:35 | <AryehGregor> | I'll go with WebKit here, since it's more consistent with other Range APIs, unless anyone has objections. |
| 18:35 | <AryehGregor> | (the API was never standardized before now, it's not in DOM 2 Range) |
| 18:36 | <smaug____> | I'd go for false |
| 18:36 | <AryehGregor> | Why? The other Range APIs all throw IndexSizeError in those cases, right? |
| 18:36 | <smaug____> | because of the reason you gave yesterday ;) |
| 18:36 | AryehGregor | reviews the other APIs for inspiration |
| 18:37 | <smaug____> | but, need to go now |
| 18:37 | <AryehGregor> | If the point is in a different document, it makes sense to return false. It's a legitimate point that's not in the range. |
| 18:37 | <AryehGregor> | If the point isn't a valid boundary point at all, the question doesn't even make sense. |
| 18:37 | <AryehGregor> | It's not clear that false is the right answer. |
| 18:37 | <AryehGregor> | If I do range.isPointInRange(node, -1) and node is entirely contained within range, is false really the correct answer? |
| 18:38 | <AryehGregor> | Oh, wait. |
| 18:38 | <AryehGregor> | Gecko actually returns true in that case . . . |
| 18:38 | AryehGregor | tests a bit more |
| 18:39 | <AryehGregor> | For an invalid offset, Gecko seems to return true if the node is entirely contained in the range, like with selectNode. But false if it's not, even if every legitimate boundary point in it is contained, like with selectNodeContents. |
| 18:39 | <AryehGregor> | Too weird. |
| 18:39 | <AryehGregor> | I'll go with WebKit. |
| 18:47 | <erlehmann> | AryehGregor, throwing is more useful than false. |
| 18:47 | <erlehmann> | from a dev point of view |
| 18:47 | <AryehGregor> | Agreed. |
| 18:48 | <erlehmann> | no error console will log false |
| 18:49 | <erlehmann> | “should asking for the fifth element in a list with four elements return an empty string or crash the program” is actually an interesting question to ask people, even those who have nothing to do with programming. |
| 18:50 | <erlehmann> | i think it tells me something about their approach to solving problems. |
| 18:51 | <erlehmann> | my little sister, who is 10 and only recently learned a tiny bit of python was convinced that such a program should crash. |
| 18:51 | <erlehmann> | because it would help her to fix the program. |
| 18:51 | <erlehmann> | my mother says it should return empty or null or just something. |
| 18:51 | <erlehmann> | to not interrupt the flow of things. |
| 18:57 | <AryehGregor> | What should isPointInRange() do if passed a doctype? WebKit throws InvalidNodeTypeError, while Gecko ignores the offset and returns true or false depending on whether the doctype is in the range or not. |
| 18:58 | <AryehGregor> | Hmm. |
| 18:58 | <AryehGregor> | Kind of like with bogus offsets. |
| 18:58 | <AryehGregor> | I think I'll go with WebKit for consistency. |
| 18:59 | <AryehGregor> | It seems like if the point isn't a valid boundary point, Gecko just ignores the offset and tests whether the node itself is in the range. |
| 18:59 | <AryehGregor> | Ooh, WebKit treats the second argument as optional. |
| 18:59 | AryehGregor | tests that |
| 19:00 | <AryehGregor> | It just defaults to 0. |
| 19:00 | <AryehGregor> | I think I won't allow that. |
| 19:07 | <AryehGregor> | What should a function throw if passed too few arguments, per spec? |
| 19:07 | <AryehGregor> | I guess that's in WebIDL? |
| 19:07 | <AryehGregor> | Or shouldn't it? |
| 19:10 | <AryehGregor> | What is R here? http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm |
| 19:10 | <AryehGregor> | I don't see it defined. |
| 19:14 | <jgraham> | AryehGregor: Umm, maybe? |
| 19:14 | <jgraham> | We need a better review tool for sure |
| 19:16 | <AryehGregor> | I'd start with *any* review system. |
| 19:17 | <jgraham> | Yeah :) |
| 19:17 | <AryehGregor> | Like, attaching patches to Bugzilla. |
| 19:17 | <AryehGregor> | I'd do that if there were a Bugzilla component. |
| 19:17 | <jgraham> | I think there is |
| 19:17 | <jgraham> | I don't know if I get email from it though |
| 19:17 | <jgraham> | I can probably set it up if not |
| 19:22 | <AryehGregor> | Where is it? |
| 19:23 | <jgraham> | I don't know, I never needed to file a bug :p |
| 19:23 | <jgraham> | Maybe MikeSmith or plh knows |
| 19:24 | <MikeSmith> | bugzilla component for what? |
| 19:24 | <MikeSmith> | WebIDL? |
| 19:24 | <jgraham> | testharness.js |
| 19:26 | <MikeSmith> | oh |
| 19:26 | <MikeSmith> | yeah, we have component for it |
| 19:26 | MikeSmith | finds it |
| 19:26 | <MikeSmith> | http://www.w3.org/Bugs/Public/enter_bug.cgi?product=Testing&component=testharness.js |
| 19:30 | <bfrohs> | Where would be the best place to suggest adding nav-index-scope to css ui? And making sure counter() values can be used for nav-index? Anyone? |
| 19:34 | <AryehGregor> | bfrohs, www-style is for CSS changes. |
| 19:34 | <AryehGregor> | CC the editor of the relevant spec. |
| 19:35 | <bfrohs> | AryehGregor, thank ya |
| 19:36 | <heycam> | AryehGregor, extra arguments are ignored |
| 19:36 | <heycam> | AryehGregor, and that last line should be "Return candidates" |
| 19:36 | <heycam> | though I thought I'd already fixed that... |
| 19:36 | <AryehGregor> | heycam, but passing too few throws a TypeError, if I'm reading right? |
| 19:37 | <heycam> | AryehGregor, yeah |
| 19:37 | <AryehGregor> | There's another mention of R a couple lines before, by the way. |
| 19:37 | <heycam> | oh ok |
| 19:37 | heycam | notes it down |
| 19:46 | <AryehGregor> | jgraham, http://www.w3.org/Bugs/Public/show_bug.cgi?id=14589 |
| 19:46 | <AryehGregor> | You're the assignee, so I assume you got e-mail. |
| 19:47 | <AryehGregor> | I'll commit the patch if you like, just give me the okay. |
| 20:19 | <AryehGregor> | Hmm. Can we kill detach()? It seems utterly, absolutely useless. |
| 20:19 | <AryehGregor> | And it adds a line to every single Range attribute/method. |
| 20:23 | <Hixie> | how do i create a file on windows with a specific set of bytes as the file name? |
| 20:23 | <Hixie> | i want to do the equivalent of: |
| 20:23 | <Hixie> | echo -e '\xE1\xBA\x9B\xCC\xA3\xE2\x84\xAB.txt' | xargs touch |
| 20:24 | <AryehGregor> | Are Windows filenames sequences of bytes? |
| 20:24 | <AryehGregor> | They're not UCS-2 or something? |
| 20:24 | <Hixie> | i can do sequences of unicode characters if there's a way to do that too |
| 20:25 | <Hixie> | U+1E9B U+0323 U+212B . t x t |
| 20:25 | <Hixie> | but i don't want, e.g., notepad.exe to be doing any munging of the characters before i save |
| 20:25 | <Hixie> | so i don't want to use a text box to do it |
| 20:25 | <Hixie> | if i can avoid it |
| 20:27 | <Hixie> | (how would i even do it there?) |
| 20:27 | <hober> | Hixie: you could use emacs |
| 20:28 | <_bga> | Hixie i recomend you install msys |
| 20:28 | <Hixie> | msys? |
| 20:29 | <Hixie> | hober: no emacs (and don't really want to install anything if i can help it) |
| 20:29 | <_bga> | Hixie http://www.mingw.org/wiki/MSYS |
| 20:29 | <Hixie> | i wouldn't trust such a system not to futz with the bytes between the shell and the file system |
| 20:29 | <Hixie> | too many levels of indirection involved |
| 20:39 | <zewt> | Hixie: filenames on ntfs are stored in UTF-16 (actually, just arbitrary 16-bit characters), so you can't use a "specific set of bytes" |
| 20:40 | <MikeSmith> | learning about https://wiki.mozilla.org/Auto-tools/Projects/Marionette |
| 20:51 | <zewt> | Hixie: also, notepad is a pretty safe way to create filenames in unicode, because it's a unicode application itself (most programs are ANSI, which will trigger locale-specific conversions) |
| 20:52 | <Hixie> | zewt: 16 codepoints are bytes too :-) |
| 20:52 | <Hixie> | zewt: my concern is over unicode normalisation |
| 20:52 | <Hixie> | zewt: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 |
| 20:56 | <zewt> | well, i created \u03D3\u03D2\u0301.txt in File Explorer, and it doesn't appear to have normalized it at all |
| 20:56 | <Hixie> | yeah that was my experience too, see the last comment on the bug |
| 20:59 | <zewt> | for real headaches: illegal code sequences in filenames exposed to JS ... |
| 20:59 | <zewt> | (a question FileAPI will have to figure out at some point) |
| 21:02 | <Hixie> | Philip`: would be good to have tests like http://test.w3.org//html/tests/submission/PhilipTaylor/canvas/security.pattern.canvas.fillStyle.html that check interaction with document.domain (i'm about to change the spec on this to use the effective origin) |
| 23:00 | <kennyluck> | Hmm.. the mbox archive output by whatwg.org doesn't do >From quotation. |
| 23:06 | <ojan> | Hixie: is the case-sensitivity of attribute names for svg in html specified anywhere? |
| 23:06 | <ojan> | Hixie: i'm having trouble finding it in the html spec |
| 23:06 | <Hixie> | case-sensitivity in what sense? |
| 23:07 | <ojan> | Hixie: in regular html, attribute names are lowercased |
| 23:07 | <Hixie> | you mean when parsing? |
| 23:07 | <ojan> | Hixie: in regular svg, attribute names keep their case |
| 23:07 | <ojan> | Hixie: yeah |
| 23:07 | <Hixie> | aah |
| 23:08 | <Hixie> | yeah that's in the parser |
| 23:08 | <Hixie> | hold on |
| 23:08 | <Hixie> | i'll give you a search string |
| 23:08 | <ojan> | Hixie: great |
| 23:08 | <Hixie> | search for "adjust SVG attributes" |
| 23:10 | <ojan> | Hixie: so basically, we parse it ignoring case and then spit out the case-sensitive result? |
| 23:10 | <Hixie> | yeah |
| 23:10 | <Hixie> | well |
| 23:10 | <Hixie> | we spit out a case-normalised result |
| 23:10 | <ojan> | Hixie: e.g. paThLength -> pathLength ? |
| 23:10 | <Hixie> | right |
| 23:10 | <ojan> | Hixie: ok...here's the problem we're running into... |
| 23:11 | <Hixie> | paThLength in the markup becomes pathlength in the parser becomes pathLength in the DOM |
| 23:11 | <ojan> | Hixie: selector parsing says the case-sensitivity of attirbute name/value parsing depends on the document type |
| 23:11 | <ojan> | Hixie: so, webkit always lowercases attribute names in html documents |
| 23:12 | <Hixie> | that's changed iirc |
| 23:12 | <ojan> | Hixie: so now *[pathLength] doesn't match <svg pathLength="..."> |
| 23:12 | <ojan> | because the attribute name in the selector is lowercased and the one on the svg element isn't |
| 23:12 | <ojan> | Hixie: it doesn't seemd changed to me in the selectors 4 spec |
| 23:13 | <Hixie> | hmm, i may be thinking of attribute _values_ |
| 23:13 | <ojan> | Hixie: http://dev.w3.org/csswg/selectors4/#attribute-case |
| 23:13 | <Hixie> | yeah i'm thinking of values, don't mind me |
| 23:13 | <Hixie> | let's see |
| 23:14 | <Hixie> | ok so the HTML spec says that "and element names of HTML elements in HTML documents must be treated as ASCII case-insensitive for the purposes of selector matching" |
| 23:14 | <Hixie> | so [pathLength] should match <div pathlength> but not <svg pathlength> |
| 23:15 | <ojan> | Hixie: yes...but the problem is that it's currently impossible as speced to match <svg pathlength> |
| 23:16 | <Hixie> | [pathLength] would match it |
| 23:16 | <Hixie> | since the parser would convert it to pathLength in the DOM |
| 23:17 | <ojan> | Hixie: oh...i guess it's technically wrong that webkit lowercases the attribute name in the css parser |
| 23:17 | <ojan> | it should just be doing a case-insensitive compare |
| 23:17 | <ojan> | for html elements |
| 23:17 | <Hixie> | yeah |
| 23:17 | <Hixie> | html elements in html documents |
| 23:17 | <ojan> | right |
| 23:17 | <ojan> | sigh |
| 23:24 | <ojan> | Hixie: arv is suggesting that selector attribute matching in an HTML document shoudl always be case-insensitive regardless of what element you're matching |
| 23:26 | <ojan> | Hixie: why not make svg attributes in html documents lowercase like all other attributes? |
| 23:26 | <Hixie> | well the attributes being lowercase would mean that there'd be two SVG vocabularies |
| 23:26 | <Hixie> | one with lowercase names and one not |
| 23:26 | <Hixie> | which would have rammifications i can't even fully imagine |
| 23:27 | <hober> | ojan: DOM Consistency, basically |
| 23:27 | <Hixie> | but would certainly be a disaster for implementors |
| 23:27 | <Hixie> | consider the confusion that would result from taking an SVG file and moving the nodes to an HTML file and finding it all stopped working, e.g. |
| 23:27 | <Hixie> | anyway, that's one thing |
| 23:28 | <Hixie> | the other thing is case-sensitivity |
| 23:28 | <Hixie> | i don't really mind what we do there, that's an issue for the css and svg groups to decide |
| 23:28 | <Hixie> | i expect css would say it's up to svg, css just delegates to the host language |
| 23:28 | <Hixie> | and i've no idea what the svg group would want |
| 23:28 | <Hixie> | i haven't worked out what their operating principles are |
| 23:28 | <shepazu> | I could ask them |
| 23:29 | <shepazu> | for SVG2, we are not claiming it is an XML syntax, but a DOM one |
| 23:29 | <Hixie> | ojan, shepazu; shepazu, ojan. |
| 23:29 | Hixie | steps back :-0 |
| 23:29 | <shepazu> | (though there is, of course, an XML parsing) |
| 23:30 | <ojan> | Hixie, shepazu: people here are suggesting that maybe we should do the HTML normalization of svg attribute names at attribute matching time |
| 23:30 | <shepazu> | Hixie: at least, that's what I said in the charter that's up for review now |
| 23:30 | <Hixie> | ojan: what would that mean? |
| 23:30 | shepazu | is not sure what the implications of that are, ojan |
| 23:32 | <shepazu> | Hixie: fyi http://www.w3.org/Graphics/SVG/2011/charter.html |
| 23:32 | <shepazu> | [[ |
| 23:32 | <shepazu> | The SVG WG develops the following technologies: A markup syntax, compatible with XML and HTML5 parsing, for describing shapes, text, and painting effects, including gradients, filters, and other graphical effects, through a set of elements and attributes. |
| 23:32 | <shepazu> | ]] |
| 23:33 | <shepazu> | so, I don't say "DOM", but that's the implication |
| 23:33 | <shepazu> | (or something) |
| 23:34 | <ojan> | shepazu: the implication is that *[pathlength] would match <svg pathLength=5> |
| 23:35 | <Hixie> | ojan: would it match <div pathlength>? |
| 23:35 | <shepazu> | ojan: seems friendly to me, but not sure about the implementation fallout |
| 23:35 | <ojan> | Hixie: yeah |
| 23:35 | <Hixie> | shepazu: "a markup syntax, compatible with XML and HTML5 parsing" is, like, the opposite of a "DOM"... |
| 23:35 | <shepazu> | Hixie: ok, patches welcome |
| 23:35 | <ojan> | it's a performance tradeoff as far as implementation is concerned |
| 23:36 | <Hixie> | shepazu: i think charters are irrelevant, so i don't mind either way, i'm just saying that if you meant to say DOM, you should be aware that what you just quoted says the opposite :-) |
| 23:36 | <shepazu> | ojan: I'm more concerned about backward-compatibility |
| 23:36 | <Hixie> | ojan: i don't understand what "do the HTML normalization of svg attribute names at attribute matching time" means then. |
| 23:36 | <ojan> | with *[pathlength] matching <svg pathLength=5>, you can store only the lower-cased copy of the attribute name and for html elements, the name comparison is very fast, but it's slower for svg elements |
| 23:36 | <shepazu> | Hixie: too jetlagged to follow you, but interested to hear an explanation I could unpack later |
| 23:37 | <ojan> | Hixie: basically...when parsing *[pathLenGTH] we'd normalize it to *[pathlength]... |
| 23:37 | <Hixie> | shepazu: sure, ping me if you want to talk about it |
| 23:37 | <Hixie> | ojan: how do you know to normalize it? |
| 23:37 | <ojan> | Hixie: then when doing selector matching, if it's an SVG element we'd actually compare to pathLength |
| 23:37 | <erlehmann> | ojan, but pathLenGTH is WRONG |
| 23:37 | <erlehmann> | oh okey |
| 23:37 | <ojan> | erlehmann: for HTML elements, it would match |
| 23:38 | <erlehmann> | i hate every single member of your working group for that |
| 23:38 | <erlehmann> | ;) |
| 23:38 | <Hixie> | ojan: i mean, what if MathML had a "foobar" attribute and SVG had a "fooBar" attribute? |
| 23:38 | <erlehmann> | Hixie, namespac- oh wait. |
| 23:39 | <Hixie> | ojan: and would you match [pathlength] to an <svg> element that had a "pathlength" attribute manually set in the DOM? (lowercase, so not the real pathLength one?) |
| 23:39 | <ojan> | Hixie: what about it? *[foobAr] would match both of them |
| 23:39 | <ojan> | Hixie: yeah...i guess that doens't make sense |
| 23:39 | <ojan> | Hixie: sigh...svg in html... :( |
| 23:39 | <erlehmann> | well, seems “claiming SVG is not XML, but a DOM syntax” needs some work. |
| 23:40 | <Hixie> | ojan: "just" do the comparison case-insensitively against HTML elements and case-sensitively against non-HTML elements |
| 23:40 | <ojan> | Hixie: yeah...fine. |
| 23:40 | <Hixie> | ojan: it means having both strings in the comparison function, and one extra pointer check for each node |
| 23:40 | <Hixie> | ojan: not the end of the world |
| 23:40 | <ojan> | Hixie: yeah |
| 23:40 | <Hixie> | perf-wise |
| 23:41 | <ojan> | Hixie: yeah...it means storing an extra string if you want to keep the performance for html element matching |
| 23:41 | <Hixie> | yeah but you have that extra string anyway today, right |
| 23:41 | <ojan> | but attribute selectors are not widely used enought for it to really matter |
| 23:41 | <erlehmann> | why not something like *[html:pathlenght|svg:pathLength] |
| 23:41 | <Hixie> | or are you flattening it during parsing? |
| 23:41 | <ojan> | Hixie: no, right now webkit only stores the lowercased string |
| 23:41 | <erlehmann> | what am i missing? |
| 23:41 | <Hixie> | css parsing |
| 23:41 | <ojan> | yeah |
| 23:41 | <Hixie> | ah ok |
| 23:41 | <Hixie> | yeah that's unfortunate |
| 23:41 | <Hixie> | are you atom-ifying these strings? |
| 23:41 | <ojan> | meh, like you said it's not a big deal |
| 23:42 | <ojan> | Hixie: atom-ifying? |
| 23:42 | <Hixie> | whatever terminology webkit uses... converting them to a pointer rather than storing the literal string |
| 23:42 | <ojan> | Hixie: ah. yes. |
| 23:42 | <Hixie> | ok so it's really just one extra pointer |
| 23:42 | <Hixie> | plus a pointer check |
| 23:43 | <Hixie> | plus you get to flatten the logic for xml and html |
| 23:43 | <ojan> | Hixie: i'm not sure we'd atomify the non-lowercased string |
| 23:44 | <Hixie> | why not? |
| 23:44 | <ojan> | Hixie: creating AtomicStrings isn't free |
| 23:44 | <ojan> | Hixie: the main reason you do it is so you can have quick string comparisons |
| 23:44 | <Hixie> | yeah but the cost has to be offset against the many comparisons you're going to be doing |
| 23:44 | <Hixie> | and the same string will likely exist in the DOM too, right |
| 23:44 | <Hixie> | anyway |
| 23:45 | <Hixie> | what do i know :-) |
| 23:45 | <ojan> | oh...i guess for the non-lowercase one we'd still just be doing a case-senstiive comapre...so we probably would. you're right |
| 23:45 | <ojan> | yeah...so in the common case it would not be considerably more memroy |