00:34
<Hixie>
should start < loopStart < loopEnd < end be enforced, or should it be possible to have a timeline like |---<loopStart>---<start>---<loopEnd>---<end>---|
00:34
<Hixie>
?
00:34
<Hixie>
(othermaciej?)
00:37
<Lachy_>
I don't think it would make sense to have loopStart before start
00:37
<Lachy_>
but shouldn't it be start <= loopStart < loopEnd <= end
00:37
<othermaciej>
Hixie: yo
00:37
<othermaciej>
Hixie: in meeting
00:38
<Hixie>
you could imagine a case where you loop and you have a sound between the loops but not at the start or end
00:38
<Hixie>
that would need loopStart or loopEnd to be outside the start...end bit
00:38
<othermaciej>
Hixie: I'm not sure - seems like there is no need to force it
00:38
<Hixie>
k
00:39
<Hixie>
we do have to assume that the starts are before the ends, i think
00:39
<othermaciej>
yes
00:40
<othermaciej>
impossible to splice together a sane timeline otherwise
00:41
<Hixie>
yeah
05:32
<tylerr>
Evening all.
05:35
<Lachy_>
Hi tylerr
05:35
<tylerr>
Hey! Lachy_, how's it going? :-)
05:37
<Lachy_>
I'm fine, u?
05:37
<Lachy_>
how are you going with those articles? made any progress?
05:37
<tylerr>
Trying to come up with a half-witty, half-relevant site name.
05:38
<Lachy_>
I thought you were just going to publish them on the whatwg blog
05:38
<tylerr>
Oh I am, this is for my personal one. :-)
05:38
<tylerr>
And I've got the groupings figured out. I'm now working on use cases.
05:39
<Lachy_>
are you trying to plan all articles at the same time, or just working on 1 at a time?
05:39
<tylerr>
Working on one group at a time.
05:40
<tylerr>
So say for the "prose" section, I'd like a few use cases.
05:42
<tylerr>
One that covers <p> and <hr>/<br> and one that covers <dialog>.
05:42
<tylerr>
So on and so forth through the rest of the sections.
05:43
<tylerr>
I'll also have an article that addresses the various predefined class names.
05:46
<Lachy_>
<dialog> is easy: IRC or instant message chat logs!
05:47
<tylerr>
Lachy_: You read my mind. :-)
05:47
<Lachy_>
I don't think you should really bother covering such basic elements as <p>, <br>, <hr>, etc. They're already widely used and generally people know what they're for
05:47
<tylerr>
Can you imagine <dialog> tags injected with Microformat hCard code? Mmm...
05:48
<Lachy_>
nah, that was one of the use cases we had in mind when we came up with dialog
05:48
<tylerr>
Oh sure, that would be for my beginner articles.
05:48
<tylerr>
Ahh.
05:48
<Lachy_>
it was also to address the mistake in HTML4 that <dl> could be used for dialog
05:49
<tylerr>
Aye, I always wondered about that. Now it makes sense to use <dt> and <dd> inside a <dialog>.
05:49
Lachy_
wants to do one on video soon, as soon as the draft stabalises
05:49
<tylerr>
Nice!
05:49
<tylerr>
I'd consider doing a <canvas> to start.
05:50
<Lachy_>
I don't want to do canvas, it's been done before (elsewhere)
05:50
<Lachy_>
but you can do it
05:50
<tylerr>
Oh. I'll find the link. I don't want to reinvent the wheel.
05:50
<tylerr>
I'd rather "pave the cowpaths". ;-)
05:50
<tylerr>
Instead of widen the road.
05:50
<Lachy_>
there's plenty of articles on canvas, it's been around for nearly 2 years
05:50
<Lachy_>
look up Plot Kit
05:51
<tylerr>
Ah see, this is what I get for wanting to expand my horizons in web development only a month or so ago.
05:51
<tylerr>
Thanks will do.
05:51
<Lachy_>
also ExplorerCanvas on source forge
05:52
<tylerr>
So far all I've focused on is accessibility and standards-based design, so I haven't explored many of the custom elements.
05:52
<tylerr>
*browser elements
05:53
<tylerr>
What's the port for the W3 server? I'm setting up my home connection to it.
05:56
<Lachy_>
the IRC server?
05:56
<Lachy_>
irc://irc.w3.org:6665/html-wg
05:56
<tylerr>
Great thanks! (was looking for the 6665 part)
16:40
<annevk>
http://doyouwanttodie.com/2007/03/27/more-changes/
16:40
<annevk>
(my reply is a reference to what he wrote on his about page)
16:52
<gavin_>
haha
16:54
<gsnedders>
reality sucks
17:01
<Dashiva>
annevk is going all philosophical on us
17:01
<Dashiva>
next it'll be analogies about butterflies and boulders, no doubt about it
18:18
<othermaciej>
hello all
18:19
<annevk>
hi maciej
18:19
<Hixie>
hey
18:21
<othermaciej>
hi annevk
18:21
<othermaciej>
hello Hixie
18:22
<annevk>
Hixie, when will you commit the new video stuff so I can read some diff?
18:22
annevk
reads /source atm
18:24
<annevk>
also, " If the same URI has been registered multiple times, removing it must only remove one instance of that URI for each invokation of the method." contains a markup error around "method"
18:24
<annevk>
everything after it is marked up as <code>
18:25
<Hixie>
annevk: when it's done, right now i have a few more paragraphs to do
18:26
<annevk>
fair enough
18:26
<Hixie>
it'd be done last week if i hadn't started feeling ill over the weekend and then had the csswg meeting this week
18:27
<Hixie>
markup should be fixed
18:28
<Philip`>
(For that quote: "Did you mean: invocation")
18:31
<othermaciej>
wow, Gerv got really worked up over codecs
18:31
othermaciej
wonders whether to reply or just let the conversation end
20:24
<hsivonen>
Hixie: is <video> v1 going to have a default scriptless way to start and stop the video?
20:24
<annevk>
contextmenu
20:26
<hsivonen>
I think v1 should, by default, allow controller UI on hover and at minimum allow play/stop without script, e.g. by clicking the video.
20:27
<hsivonen>
disabling these should be done by the script when the script wants to take over
20:27
<hsivonen>
if minimum default UI isn't in v1, it is going to hurt later on
20:27
<hsivonen>
and disabling the UI via an attribute is bad, because it isn't known if scripts will run
20:28
<hsivonen>
s/at minimum allow/at minimum require/
20:30
<annevk>
the idea is to enable the UI through an attribute
20:32
<hsivonen>
annevk: I disagree then. I haven't read all the <video> messages, yet, so I've been hesitant to send my UI-related opinions to the list
20:32
<Hixie>
we're already past v1
20:32
<om_lunch>
I don't think you want both UA ui and custom script-driven UI on the same element
20:32
<Hixie>
but we're going to have a declarative way of enabling ui, yes
20:32
<othermaciej>
(good day gentlemen)
20:32
<hsivonen>
Hixie: why not script-based disabling of the UI?
20:32
<Hixie>
or that
20:32
<Hixie>
same idea basically
20:33
<hsivonen>
Hixie: more reliable
20:33
<Hixie>
i agree the second is more reliable
20:33
<Hixie>
it also causes flicker though
20:33
<othermaciej>
the conditions under which you have video but not script seem unlikely
20:33
<othermaciej>
except for people with a script phobia that exceeds their desire to successfully browse the web
20:33
<hsivonen>
Hixie: not if the spec gives guidance that the UI should not change the dimensions of the replaced element
20:34
<hsivonen>
e.g. it should be superimposed on hover as in iTunes or full-screen QuickTime Player
20:34
<othermaciej>
doesn't that go a bit too far in mandating the UI?
20:35
<othermaciej>
especially since very little web-based video has a UI like that currently?
20:35
<hsivonen>
othermaciej: the use case is that you aren't youtube and just want to include video to illustrate some prose
20:35
<othermaciej>
hsivonen: in which case you say <video ui=on> or whatever
20:36
<hsivonen>
othermaciej: considering all the issues Apple's own docs have had to cover about the movie controller height, I'm pretty convinced that a superimposed UI is the way to go
20:36
<othermaciej>
hsivonen: well, the HTML spec seems like a bad place for novelties in UI design
20:36
<hsivonen>
othermaciej: it is not novel. QuickTime supports it already
20:37
<othermaciej>
can you point me to a web video with hover controls?
20:37
<Hixie>
hsivonen: we're not mandating ui (what if the ui is that the controls are in another window, and the window can dock to hte <video>, and...)
20:37
<Hixie>
hsivonen: but i'm sure there's a good solution for this, i'll look into it when i'm doing fixing looping and seeking
20:37
<hsivonen>
Hixie: sure, but you could mandate that the UI mustn't change the size of the replaced element rectangle
20:38
<Hixie>
othermaciej: opera's second <video> element demo implements their ui by hovering over the video :-)
20:38
<hsivonen>
othermaciej: I don't have Web examples off the top of my head although I have a feeling that I've seen such Flash
20:39
<annevk>
Hixie, we have a native UI or you mean controls done by the page?
20:39
<hsivonen>
othermaciej: anyway, the precedent I'm citing is iTunes
20:39
annevk
should prolly download some internal builds...
20:39
<othermaciej>
hey, I don't think hover UI is bad or wrong, I just think it's not the norm, so saying UAs are required to do it is inappropriate (even more so than normal mandating of UI)
20:40
<hsivonen>
othermaciej: how would you otherwise deal with the size of the replaced element rectangle staying predictable?
20:42
<othermaciej>
hsivonen: I'm guessing default UI controls are most likely to be desirable in cases where you are not doing extensive pixel-perfect styling; but regardless, as long as there is a way to set the size of the video content box, I think that is good enough
20:42
<Hixie>
annevk: native
20:42
<Hixie>
oh
20:42
<Hixie>
uh
20:43
<Hixie>
"we" = oper
20:43
<Hixie>
a
20:43
<Hixie>
you have html controls by the page
20:43
<Hixie>
which overlay the <video>
20:43
<annevk>
we should prolly unify the <video> events and progress events...
20:43
<hsivonen>
othermaciej: I don't know if the QuickTime for Windows controller is now as tall as the Mac version, but in the past it wasn't and it sucked big time for QuickTime embedding
20:43
<Hixie>
they are
20:43
<annevk>
Hixie, ah ok
20:43
<annevk>
progress events doesn't have "stalled" and "begin" is "loadstart"
20:44
<Hixie>
they have 'begin' last i checked
20:44
<Hixie>
'stalled' is new, yes
20:44
<annevk>
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.10
20:44
<Hixie>
but that's video-specific probably
20:44
<Hixie>
when did begin become loadstart
20:44
<Hixie>
weird
20:44
<Hixie>
ok
20:44
<Hixie>
well the idea is that they are synced
20:45
<annevk>
k
20:45
<Hixie>
i'll fix it again when one of the two drafts is more stable
20:45
<Hixie>
(either one)
20:45
<othermaciej>
hsivonen: I agree it's annoying - default controller will probably only be useful for cases like having it as a <figure> in the middle of a blog post where you don't care about metrics of the whole element
20:46
<othermaciej>
is "stalled" really needed?
20:46
<othermaciej>
isn't what you really care about current expectation of playability, not network transfer rate?
20:46
<hsivonen>
othermaciej: authors tend to care about metrics anyway when they are happy with non-scripted play control
20:47
<annevk>
maybe <figure> around <video> can imply ui=on ?
20:47
<othermaciej>
you could still reasonably have custom controls inside a <figure>
20:47
<annevk>
not with the current semantics of <figure>
20:48
<Hixie>
can't find when begin became loadstart. weird.
20:48
<Hixie>
oh well
20:48
<hsivonen>
annevk: implicit stuff like that could become confusing
20:48
<othermaciej>
I complained about it being "begin" I think
20:48
<Hixie>
what should we do if 'start' or 'loopstart' or 'loopend' or 'end' are beyond the end of the clip?
20:48
<Hixie>
othermaciej: ah :-)
20:49
<othermaciej>
Hixie: they should be limited to [0, duration]
20:49
<annevk>
duration isn't necessarily known
20:50
<Hixie>
othermaciej: k
20:50
<othermaciej>
annevk: to the author, or to the UA?
20:50
<othermaciej>
in the Apple proposal we had language about what to do for not-yet-known duration and for unbounded streams
20:51
<othermaciej>
(don't remember details)
20:51
<annevk>
the UA
20:51
<annevk>
well, author too I suppose
20:51
<othermaciej>
unknown duration is NaN, and in that case you can't really put limits on timeline bounds, stream would be +Inf
20:52
<othermaciej>
(I think)
20:52
<othermaciej>
I'm not sure all the features have been carefully considered in light of streaming
20:52
<annevk>
i hope someone will scream in case of conflict :)
20:53
<othermaciej>
well, not a lot of people have been doing close review of the details
20:53
<othermaciej>
Apple folks will definitely continue to review
20:53
<othermaciej>
I think we will also be proposing some more features based on our open issues doc
20:54
<annevk>
I wonder how captioning will work
20:54
<annevk>
some kind of external file?
20:54
<othermaciej>
accessibility is one of the first things we want to address
20:54
<othermaciej>
multimedia formats can have timed text tracks
20:54
<othermaciej>
in multiple languages even
20:54
<Hixie>
yeah i need to do a careful review to handle unbounded and unknown duration
20:55
<othermaciej>
the tricky part is how to select which tracks to play
20:55
<Hixie>
still, one thing at a time :-)
20:55
<annevk>
yeah, I heard chaals ask for multilangual support
20:55
<othermaciej>
they can also have multi-language soundtracks
20:56
<hsivonen>
annevk: the WHATWG probably should avoid reinventing captioning
20:56
<Hixie>
good lord yes
20:56
<hsivonen>
annevk: it has already been specced for the Ogg family and for the MP4 family
20:56
<Hixie>
i was hoping that we'd just let the UA offer the UI for that in the context menu (egg)
20:56
<Hixie>
eg, even
20:56
<othermaciej>
what we need is support for controlling the captioning already in video
20:57
<othermaciej>
but not, IMO, a new format for captions
20:57
<hsivonen>
although Apple's implementation exhibits serious suckage if the filename ends in .mp4 instead of .3gp
20:57
<hsivonen>
(doesn't make sense)
20:57
<othermaciej>
really? what happens?
20:58
<othermaciej>
does it work for .m4v?
20:58
<hsivonen>
othermaciej: things become rediculously CPU-intesive and therefore potentially slow
20:58
<hsivonen>
dunno
20:58
hsivonen
looks up markp's post
20:58
<othermaciej>
that's really weird
21:00
<hsivonen>
http://diveintomark.org/archives/2006/07/27/imagination#comment-7180
21:00
<hsivonen>
also http://diveintomark.org/archives/2006/07/23/video-howto
21:02
<othermaciej>
well, I'll point it out to our media guys
21:02
<met_>
annevk, http://glazman.org/weblog/dotclear/index.php?2007/03/28/3391-answer-to-anne-van-kesteren
21:03
<othermaciej>
I don't think generic MPEG-4 should imply codec restrictions, but maybe it does for some reason
21:03
<annevk>
met_, I saw, but wasn't entirely sure what he meant
21:03
<met_>
still not read it fully
21:04
<hsivonen>
othermaciej: IIRC, the container has an artificial restriction so that you mustn't put in non-MPEG (or non-MPEG-4?) video and audio
21:04
<hsivonen>
othermaciej: .3gp stretches the audio side to allow AMR
21:04
<annevk>
http://www.w3.org/TR/NOTE-link doesn't seem to solve the issues I pointed out, but maybe he meant something else...
21:05
<othermaciej>
hsivonen: I tried to get the media folks to explain it to me - apparently, the "ISO Base File Format" has no restrictions, but MPEG-4 also includes specs of restricted versions and descriptions of how to include certain codecs
21:07
<met_>
annevk, just read is, feel littel confused too
21:07
<met_>
s/is/it/
21:19
<Hixie>
i just regenned the spec
21:19
<Hixie>
there are open issues (like when to apply 'start')
21:21
<annevk>
it doesn't deal with setting loopCount
21:21
<annevk>
is there a document btw that explains the need for looping for video?
21:23
<othermaciej>
hsivonen: audio/mpeg4-generic MIME type might have worked in markp's case
21:24
<hsivonen>
othermaciej: he seems to assume download followed by MIME-unaware playing from the disk
21:24
<hsivonen>
othermaciej: that's what I did to confirm the issue last year
21:25
<Hixie>
we're gonna have to deal with seeking to arbitrary points
21:25
<Hixie>
i thought it did deal with setting loopcount
21:25
<Hixie>
but i'll look after lunch
21:25
<Hixie>
we're gonna have to deal with seeking to points that aren't in the media, rather (e.g. because the end is unknown)
21:25
<othermaciej>
hsivonen: I don't know if there is an extension corresponding to that MIME type
21:26
<othermaciej>
I guess the real conflict is serving on web vs. supporting on ipod
21:26
<annevk>
Hixie, well, setting loopCount to 0 for instance
21:28
<annevk>
hmm, maybe I should study the algorithm more closely
21:40
<annevk>
raman makes a good point about <em> versus <i>
21:42
<annevk>
(and several other good points in related threads)
21:43
<annevk>
oh, I suppose I should have said that in #html-wg ...
21:43
annevk
schrugs
21:45
<othermaciej>
I need to figure out what people mean by "extensibility"
21:46
<othermaciej>
I'm not sure they all mean the same thing
21:46
<annevk>
<object>
21:46
<othermaciej>
I don't think that is what they mean
21:46
<othermaciej>
they want to be able to add tags
21:46
<annevk>
or as howcome recently said: <i> <object>
21:47
<annevk>
oh, right
21:47
<othermaciej>
but I'm not sure who they want to be able to add them, who should see them, and what effects adding has (styling? API? effect on conformance checkers?)
21:47
<othermaciej>
I need to understand this to know if the right answer is "use XBL"
21:47
<annevk>
mnot from Y! wants random elements (maybe namespaced) he can hang behavior to himself
21:48
<annevk>
raman from Google seems to want markup that can trigger a plugin that renders the markup
21:48
<annevk>
(prolly similar to how you can have inline SVG in HTML in IE trigger the Adobe player)
21:48
<hsivonen>
annevk: mnot? on which list?
21:49
<annevk>
his blog I think
21:49
<hsivonen>
oh
21:49
<othermaciej>
I think binary plugin APIs would be out of scope
21:49
<annevk>
and in person (otherwise / too)
21:49
hsivonen
has 1235 unread feed items
21:49
<othermaciej>
hanging behavior or styling off an element, the author can already do with CSS+JS; XBL will provide a better way
21:49
<annevk>
othermaciej, it's a processing instruction
21:50
<annevk>
but yeah, I don't think we should specify something like that
21:50
<othermaciej>
annevk: specifying the PI is pretty useless without a spec for how the plugins work, isn't it?
21:51
<annevk>
IE supports namespaces in text/html through a PI. A plugin can hook into a namespace
21:51
<annevk>
I think that's sort of how it works
21:51
<othermaciej>
sure, but what's the API for how you provide DOM elements and hook into the layout?
21:52
<othermaciej>
I'm assuming it's some ActiveX thing
21:52
<annevk>
oh, dunno
21:54
<annevk>
I'm not really convinced with the extensibility stuff. Having the community in total control of the language seems better.
21:54
othermaciej
shrugs
21:55
<othermaciej>
it sounds more like a feature request than a design principle
21:55
<othermaciej>
though HTML does have some support for extensibility, via class and defined handling for unknown elements
21:56
annevk
wonders how you'd do simplified markup yet keeping all the features
21:56
<othermaciej>
a lot of wikis do it by also letting you include HTML markup
21:57
<othermaciej>
which presumably you use in case of anything hard
21:57
<othermaciej>
but that makes it pretty hard to define parsing
21:57
<annevk>
quite
21:58
<annevk>
"architectural framework"
21:59
annevk
isn't sure how people can use that phrase lightly
22:13
<annevk>
http://www-128.ibm.com/developerworks/xml/library/x-xml2007predictions.html
22:23
annevk
-> bed
22:25
<Hixie>
annevk: as far as i can tell, changing loopCount is taken care of.
22:37
<othermaciej>
I'm surprised that IBM page doesn't mention HTML5 or the new HTML working group at all
22:38
<othermaciej>
oh, it's Elliotte Rusty Harold
22:39
<hasather>
othermaciej: it does mention HTML5. Also, it's from february so the new WG wasn't born
22:40
<Hixie>
it says "I don't see a big future for the WHAT Working Group's Web Forms 2.0. It's got some nice bells and whistles, but it doesn't change anything."
22:40
<hasather>
doesn't change anything? Right
22:41
<Hixie>
it has some other amusing quotes
22:42
<bewest>
actually that's a compliment, isn't it?
22:42
<bewest>
nice bells and whistles and doesn't change anything
22:42
<bewest>
isn't that the goal?
22:44
<Dashiva>
Some pavement for the cowpaths was part of the plan too, I think
22:45
<Hixie>
bewest: yeah that's why i quoted it. It exactly described what we tried to do, and said we succeeded.
22:45
<Hixie>
score!
22:48
<bewest>
yeah
22:48
<bewest>
high fives all around
22:50
<tylerr>
Hixie: Was that the "The Future is XHTML2" article?
22:50
<Hixie>
hm?
22:51
<bewest>
actually, it seems this author is into technology for technology's sake
22:51
<Dashiva>
He seems to like the letter x a lot
22:51
<bewest>
yeah... for a killer app to be truly successful, you probably wouldn't know what technology it used
22:52
<bewest>
so "semantic web killer app" is kind of an oxymoron
22:52
<tylerr>
Hixie: http://www-128.ibm.com/developerworks/xml/library/x-futhtml2.html?ca=dgr-lnxw87XHTML2
22:52
<tylerr>
Though it's from Jan 06.
22:52
<bewest>
tylerr: http://www-128.ibm.com/developerworks/xml/library/x-xml2007predictions.html
22:52
<tylerr>
Ah I didn't see that one.
22:52
<tylerr>
Lovely!
22:52
<bewest>
meh... it's kind of lame
22:53
<tylerr>
Ah well then I'll read it with a scowl on my face. ;-)
22:53
<bewest>
not very user-centric
22:54
tylerr
nods
22:58
<chin1>
so ar eyou the guys who are controlling the w3c draft for html 5.0 ?
22:58
<kingryan>
chin1: for some values of "control", yes
22:59
<bewest>
we control the whatwg draft of html5
22:59
<bewest>
the html-wg controls the w3c draft
23:02
<chin1>
hm weird
23:03
kingryan
just realized which room he's in :D
23:03
<chin1>
why do this ?
23:03
<bewest>
we don't know
23:03
<Hixie>
well, there wasn't a w3c draft when we started, and w3c wouldn't do it
23:03
<kingryan>
it's fun!
23:03
<Hixie>
now they are going to do it, and so we will probably just work with them
23:04
<bewest>
or they will work with us
23:04
<bewest>
or something
23:04
<bewest>
who knows
23:04
<bewest>
or they'll continue talking about spreadsheets and forums
23:04
<chin1>
well i've got a draft for you
23:04
<chin1>
hey is there a chat for the html-wg too ?
23:04
<bewest>
yes
23:07
<Hixie>
irc.w3.org port 6665 channel #html-wg
23:07
<bewest>
fwiw the w3c doesn't have a draft of anything yet
23:07
<chin1>
lol oh #htmlwg i gues chanserv is the only one who cares
23:08
<chin1>
ok who should i rant to first you guys or them ?
23:09
<othermaciej>
well, if you have a big dicussion topic, email might be the best starting point
23:09
<chin1>
you mean mailing list ?
23:10
<othermaciej>
yes
23:11
<othermaciej>
but if you give a general description of the topic you want to discuss, we could advise you even better on the appropriate forum
23:11
<othermaciej>
hello KevinMarks
23:13
<chin1>
well i see now that fx3 will support getElementsByClassName (gebcn) and if you ask me there is way to many functions that do the same thing ... getElementBy<whatever>... well a while back i was writing a simple dom parser and instantly thought why not something that could take a list of attributes to match against... well i rolled out a prototype and with some help of others it works very well now and i called it ... getElementsByAttrib
23:15
<othermaciej>
the Web API working group has a spec for something even more general than that
23:15
<othermaciej>
getElementsBySelector
23:15
<othermaciej>
which uses a CSS selector
23:15
<othermaciej>
though I think I will propose to rename it to cssQuery
23:16
<bewest>
<3 getElementsBySelector
23:17
<bewest>
dean edwards has a really nice version that optimizes it based on the browser, as well
23:18
<othermaciej>
yes, and having it native in some browsers will hopefully allow even better performance
23:19
<othermaciej>
though in that case browsers will have to make sure their selectors implementation is at least as fast as their XPath
23:19
<Hixie>
it'd better be
23:20
<chin1>
yea thats something like the jQeury approach
23:20
<chin1>
and thats a css type selector
23:20
<Hixie>
since the selectors one is run much more frequently than the xpath one...
23:20
<chin1>
well mine is a js type selector that is based on properties
23:20
<Hixie>
(like, every time you move the mouse)
23:20
<chin1>
actually it accepts 3 types of tests... scalar, regex, and your own supplied function... and things like {hasChildNodes: true} since hasChildNodes is a function it will execute it on your behalf and test it vs the given value
23:21
<chin1>
i can defitnetly see were a css selector is a huge powerfull beast
23:21
<chin1>
but its based on what css selectors can do ... why limit our selves ?
23:23
<chin1>
var el_array = gebi( { tagName: 'DIV', hasChildNodes: true, className: /car/i }, startNode, limit, depth )
23:23
<othermaciej>
CSS selectors can select based on attributes
23:23
<othermaciej>
though not an arbitrary regexp or function test
23:23
<chin1>
sorry i should of used geba not gebi as short for getElementsByAttributes
23:23
<KevinMarks>
does it do ~= ?
23:24
<chin1>
yea well in csss you can do things like type="text" sure ... but what about hasChildNodes or any other element property ?
23:24
<chin1>
whats ~= ?
23:24
<chin1>
isn't ~= a perl like syntax for regex test ?
23:25
<othermaciej>
~= in selectors is attribute token match
23:25
<othermaciej>
http://www.w3.org/TR/css3-selectors/#attribute-selectors
23:25
<chin1>
oh yea its a css feature not supported yet i haven't read into them much
23:25
<chin1>
let me read up on it
23:26
<othermaciej>
there is exact, prefix and token match
23:26
<othermaciej>
for attribtues
23:26
<othermaciej>
no regexp match
23:27
<chin1>
well like you siad mine allows you to provide a custom function to do whatever test your heart desires plus will the css selector merly verify that the element has a attribute called "hasChildNodes" or will it acurately detect that its a method and execute it to test the result ?
23:28
<chin1>
so exact would be like class="example" and you search for "example" and prefix would be like "ex" correct ?
23:28
<chin1>
i dont see what a token is though
23:28
<othermaciej>
if you want to test with custom code, you can just walk the DOM, so I'm not sure native UA support would help
23:28
<chin1>
i mean {className: /^ex/i} is a prefix
23:29
<chin1>
{className: "exact"}
23:29
<chin1>
{className: function(){/* whatever you want */}}
23:29
<chin1>
UA ?
23:29
<othermaciej>
div[class|=example] will match class="example-stuff" but not class="ex"
23:30
<chin1>
{className: function( value ){ if( value.indexOf("blah") != -1 }}
23:30
<chin1>
thats a quicker hack than using regex
23:30
<othermaciej>
div[class~=something] will match class="foo something bar baz"
23:30
<othermaciej>
for class specifically though, that is just div.something
23:31
<othermaciej>
the function thing is unlikely to be quicker to execute
23:31
<othermaciej>
anyway
23:31
<othermaciej>
I don't think this is the right forum
23:31
<othermaciej>
I think if you want to make a proposal, the Web API Working Group would be the best place to make it
23:31
<chin1>
your saying that the overhead of passing a function is slower than using a regex test ?
23:31
<othermaciej>
send mail to public-webapi⊙wo
23:32
<chin1>
from what i undersatnd indexOf is faster htan regex for simple sub string matches but if the extra function inquires that much over head you might be right i haven't tried any benchmarking
23:32
<chin1>
the idea too is that if this was natively supported it would be much faster
23:33
<chin1>
so that sthe email i would find searching on the w3.org ?
23:34
<othermaciej>
yes
23:35
<chin1>
thanks
23:35
<chin1>
well wath do you guys think ?
23:36
<othermaciej>
personally I think Selectors API is a better design
23:36
<othermaciej>
feel free to google for that
23:43
<chin1>
yea i think its great too
23:46
<bewest>
what regex?
23:52
<chin1>
the css selector thing