[whatwg] (no subject)
This is a proposal that I posted to w3.org a year ago, and it didn't really get
any debate there so I'm hoping to provoke some here, i wont go into too much
detail instead linking to the original posts but i'll give a bit of an overview
here...
Essentially the proposal is for a static DOM object which has read only settings
exposed to javascript (ultimately one day sendable via HTTP to the web server to
superceed UserAgent sniffing), the browser would be left with the task of
presenting the various options to the user (global, per domain, etc.).
Javascript
has allowed web sites and applications increased levels of functionality but at
the same time allowed for more possibilities of special effects and multimedia,
these are two seperate sides of the javascript coin and it would be useful to
have the former without being required to witness the latter.
One example I frequently use is google maps, which runs fine with javascript on
my low powered surfing laptop - until you change zoom levels - then it takes
over a minute to interpolate to the next zoom level, whilst this probably down
to
bad coding (a simple setTimeout for 2 seconds hence could force the
interpolation
effect to stop) it's a shame that this one effect brings the entire
web-application of google maps into an unusable state and personally i don't
think that the fact that my laptop doesnt have a GPU should mean i'm relegated
to
use the NOSCRIPT version of a site. For the sake of one flashy, un-needed
effect.
AFAIK there is a light version of google maps that uses little or no
javascript
but apart from the transition effect it runs fine. Which brings me back to the
proposal, if there were an AllowTransitions boolean that developers could
check
then they would know what experience to present the user with:
function Zoom_In()
{
if( window.UserPreferences.AllowTransitions )
Interpolate_To_Zoom( ++zoom );
else
Jump_To_Zoom( ++zoom );
}
this would still allow me to use the Javacsript map application on my low
powered
machine without resorting to a no-script-at-all version.
Another aspect is rich content, if i'm surfing whilst listening to mp3s i might
not want to be interrupted by sounds or videos playing and might want to turn
web-sounds off, or maybe i'm watching a movie on the train but dont want my web
mail to audibly alert me to a new mail message. Instead i could have a global
volume control (or per tab...) in my browser rather than the curernt situation
where you have to set it for each and every flash applet on each and every web
site. Also I might need roaming profiles, if I'm connected via WiFi i might be
happy to have videos playing, but if I'm out in the countryside, and i have a
limited/expensive GPRS data plan i dont want videos to suck up all my bandwidth
and money - if the browser could itself switch between high and low bandwidth
profiles then this would be a smoother user experience than again having to
bookmark a site's full and lite pages seperately, or have the site try to second
guess my desires through the capabilities my user agent string suggests.
Example properties might be:
MaxStreamRate (in Kb per seconds - with a popup warning the user if they attempt
to play something wider)
AutoPlayVideo (if false then video content should never start playing without a
direct click on a play button)
AutoPlayAudio (as above)
AudioVolume (0 = mute, 99 = full)
Note that the last two do not crosstalk - AutoPlayAudio may still be true if
AudioVolume is 0.
At the moment the user is at the whim of site builders about how to turn
features
on and of, stop and start audio, control volume or switch between lite and full
versions of sites. These sometimes need the user to be logged and/or cookies to
be remembered between sessions or instead the web host will simply attempt to
dictate the version of a site you get depending on your user agent string.
Currently most browsers allow images to be turned on and off very easily (albeit
usually buried deep in a menu tree). By centralising what it is the user wants
to
happen we can make the web a much more pleasant and consistent experience and
one
that is ready for users who may literally walk from a high bandwidth high
availability connection to a low bandwidth one whilst surfing - if their PDA or
laptop could hook into their connection settings and see that the connection
has switched wouldn't it be great if it could automatically tone the richness of
the web experience down with the user not having to lift a finger...
Revised Proposal
http://lists.w3.org/Archives/Public/public-html-comments/2008Jul/.html
Original Proposal
http://lists.w3.org/Archives/Public/public-html-comments/2008Apr/0003.html
Ric Hardacre
(MCAD, MCP, HTML,CSS JS hacker since '95)
cyclomedia.co.uk
[whatwg] Detecting Web Forms for future proof scripts?
I'm attempting to write Javascript scriptlets to emulate some of the Web Forms 2.0 spec in HTML 4 documents. Firstly, they obviously need to degrade for non-scripting UAs, which is easy enough. Secondly they need to check that they're running on a compatible scripting engine, just checking for the existence of document.getElementById is the simple way (If there are better ways then I'm always open to learning). But I'm presented with an issue, suppose for example I wanted to emulate the datalist element for a text box. I can use the DOM and some on-the fly CSS to build a Javascript emulated datalist, but how would one go about ensuring that if/when it encounters a browser that can handle the datalist that it does not execute? This is probably quite an open question and yes I'm aware of the embedding-a-select-inside-the-datalist solution to this particular example, but the general question remains: How to script WF2 functionality for current browsers in a way that both degrades AND yields to the UA when it can handle the functionality natively? Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Lists, ins/del, and a
Michel Fortin wrote: Le 29 août 2006 à 23:00, Lachlan Hunt a écrit : Michel Fortin wrote: How can we markup removed or inserted list items? Here's a general idea: ul insliSome list item/li/ins delliAnother list item/li/del /ul This can be solved by putting the ins and del elements as the only child nodes of the li elements instead. ul liinsSome list item/ins/li lidelAnother list item/del/li /ul The meaning of your markup is that you inserted and deleted some text within each list item, not that you added or deleted a list item like in mine. Semantically there is a difference, subtle maybe but still there. Another related thought we could discuss for revision control using ins and del is that they could do with a couple of attributes, a datetime and an author: pOn a dull and dreary afternoon ins datetime=2006-27-08 12:34:56 author=Ric HardacreI added this text while/ins the rain poured down/p Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] href on any element
Ian Hickson wrote: On Mon, 28 Aug 2006, Anne van Kesteren wrote: On Mon, 28 Aug 2006 11:33:43 +0200, Lachlan Hunt [EMAIL PROTECTED] wrote: It's arguably a very minor improvement, The only benefit I'm aware of is the convenience it provides to authors for hand coding, but that benefit is negligible when you consider the abilities of many authoring tools these days. Another thing that some author seem to want is to make an entire block a link, including its header and footer. Currently such things are solved with markup similar to: a href= span class=header/span span class=text/span /a ...or the currently non-conforming: a href= h2.../h2 p.../p /a We could make it conforming, I guess. The parser already supports it to some extent. I've run up against this before, the only way you can get it to conform is by repeating the anchor: h2a href=... title=... rel=etc.Foo/a/h2 pa href=... title=... rel=etc.Bar/a/p or by the previous, non semantic use of spans. All that is required is to allow the anchor to be used around block level elements. The anchor could be treated as a non element, where any plain text within is by default treated as inline. after all it's fine to surround some inline-replaced elements such as images with A but not others, such as inputs (though why anyone would want to do the latter is open to debate.) this could also lead to clearer use of named anchors too, if they were allowed to 1. surround the entire region they refer to 2. nest a name=appendix_1 h2Appendix 1/h2 h3References/h3 a name=ref_1p1. cite.../cite em.../em/p/a a name=ref_2p.../p/a /a Question is, is this backwards compatible? do existing UAs treat this as a series of a/a tag pairs or does the nesting break it? If a named-anchor surrounded it's region it would also allow screen readers (for example) to very easily jump to a footnote and read it without having to guess where to stop and return to the main text. Ric Hardacre http://www.cyclomedia.co.uk/
[whatwg] non-checked checkbox posting success?
When using checkboxes in forms i find myself doing this input type=checkbox name=foo value=true input type=hidden name=foo value=false and retrieving the value from the posted form data a bit like this if( checkbox.value == false )then bSomeBool = false; else bSomeBool = true; in the else case above checkbox.value will equal something along the lines of true, false. Does anybody think it would be good to allow a checkbox (and similar controls) to be used in a proper toggle sense? e.g. input type=checkbox name=foo toggle=true,false value=on where on/off (or setting checked) would toggle the true/false, and any values can be used in the toggle attribute: labelClick here if you have a dog input ... toggle = Dog owner,No dogs value=off ... /label I'm only attempting to provoke a discussion here, so dont take my code and attributes too seriously :-) Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Canvas 2d methods
Ian Hickson wrote: On Mon, 3 Jul 2006, Håkon Wium Lie wrote: Anyway, this is all a straw man -- this isn't the reason that the spec doesn't allow this. It doesn't allow this because Safari didn't do it this way in the first place, and changing it would likely introduce bugs (while still not helping authors for some time anyway). It's still early in the life of the canvas element, and we still have the luxury of listening to good proposals. We can deal with the minor problems that arise, and authors down the road will have a more intuitive syntax. I like the proposal. Well as I mentioned, I'm fine with the idea per se, if implementors are willing to change their implementations and fix any resulting bugs, then the spec will follow. I'm also strongly in favor of this. If only because it seems intuitive considering that this is the norm for most objects in not just the JS universe but increasingly others (e.g. C#, and you can even do it with some objects in VBs) so it's not like we're introducing an alien concept here. Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] [HTML5] Named start values for lists?
Lachlan Hunt wrote: dolphinling wrote: HTML5 brings back the |start| attribute on ordered lists. This allows a list to semantically start with a number other than one. It seems like the major use case for this is to split lists up, so that a single list is marked by multiple ols. Other use cases include the ability to include an excerpt from another list in a page while retaining the list item indexes, or breaking a long list across several pages. It would also be good if the simple number element that has been discussed over the past few weeks could reference a list item, something similar to pJohn's favorite fruit was rumoured to be bananas supn source=banana_ref/n/pre. But this has never been proven./p ol liApples Reference Source/li li id=banana_refBananas Reference Source/li liOranges Reference Source/li /ol At the mo this would equate to 2, but if another footnote reference were added below Apples then it would automagically allow the citation to change to 3. If you also wanted the reference to be an anchor (see wikipedia) then that might make things more complex, however, as you'd need a banana_ref for the number and an anchor named banana_anc, perhaps. Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] progress draft
Ian Hickson wrote: [snip] This seems to be a case where there should be one, and preferably only one, obvious way to do it holds. Well, there are two ways -- update the textContent, and update the attribute. But for the attribute, there's only one syntax. We could remove the attribute as well, and force authors to use textContent, though... i think it best to un-link the content and value as we cant predict all possible use cases, this meter value=0.4848%/meter is a simple use case, where the content and value are obviously linked but this is not: h4Uploading File/h4 meter value=0.25400k / 16,000k/meter now, the author could well be specifying min/max but if the file size is not known until the script is run then their javascript may look something like h4Uploading File/h4 meter id=themeter/meter ... eMeter.value = fUploaded / fTotal; eMeter.innerHTML = fUploaded + k / + fTotal + k; depending on if styling rules allow the value and content to both be rendered, or maybe the author is conscious of allowing the progress to be shown on different target devices. The only difference between meter and progress is the potential for progress to be dynamic. That's a big difference. It means the UI for one has to show that it is static, and the UI for the other has to show that it should end. which is laudable, and makes sense, but each will be updatable on the fly. a meter has to have this ability, e.g. allowing CNN to show the election votes cast on their home page, updated asynchronously. and with that ability will come authors who use one exclusively, merely applying style sheet rules (meter class=votes), or use either in place of the other ad hoc, depending on their styling rules. thus there's no way that a UA can be forced to show that a progress indicator is, indeed, progressing. Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Built Firefox, time to get cracking
Ian Hickson wrote: On Thu, 16 Mar 2006, Ric Hardacre wrote: title says it all really, only took me a few days of trying, heh. There's little to no chance that anything i do stick in will make it into the trunk (esp as i'm only building FX not seamonkey) but it should all be good clean fun anyway, what does anyone think i should toy with first? quite tempted to have a go at some of the forms stuff, specifically the submit button overrides (action, etc.) That would be my suggestion too, but I highly recommend discussing this with Mozilla engineers to make sure you don't work on something they either won't accept or are already working on. well ATM I'm just looking through the sources familiarizing myself. attaching a form element (apart from a submit button) to an arbitrary form looks relatively simple as the relationship for form submission is separate to the DOM. but I'm only working from the 1.5 source at the mo (i wanted to get *a* build together). Will do CVS next but like i said, i'm not really expecting my changes to make it into the trunk, but i suppose there's no harm in asking... someone got PING in there after all. Ric Hardacre http://www.cyclomedia.co.uk/
[whatwg] Built Firefox, time to get cracking
title says it all really, only took me a few days of trying, heh. There's little to no chance that anything i do stick in will make it into the trunk (esp as i'm only building FX not seamonkey) but it should all be good clean fun anyway, what does anyone think i should toy with first? quite tempted to have a go at some of the forms stuff, specifically the submit button overrides (action, etc.) Ric Hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] The problem of duplicate ID as a security issue
Yes, I saw Ric's reply. A nice suggestion, but that implies sandbox
is a documentElement by itself, or is it a DOMSandbox needing to be
defined?
Sandboxes are quite special things, so we'll need a DOMSandbox anyway.
But instead of adding things like getElementById() to the DOMSandbox
interface, I tend to make the fake document which is visible from
inside the sandbox a member of the sandbox itself. The call will look
like sandbox.document.getElementById().
I think that treating sandbox as a document object per-se may be a bit
of overkill, from a coding perspective all it should take is for the
implementing browser to flag a script as being contained within a
sandbox, or not, psudeocode:
documentGetElementByIdWrapper( elementID )
{
if( theScript.sandboxElement )
{
return theScript.sandboxElement.getElementById( elementID );
}
if( globalDocumentElement )
return globalDocumentElement.getElementById( elementID );
return null;
}
Ric Hardacre
http://www.cyclomedia.co.uk/
Re: [whatwg] The problem of duplicate ID as a security issue
Mihai Sucan wrote: Yes... but there's a need for allowing the parent document control sandboxed content. Therefore, it needs a new parameter, for example: getElementById(string id, bool search_in_sandbox). Isn't that changing the getElementById function? Of course this only a way, it could probably be done differently, without changing the function(s). perhaps: body div id=id DIV1 /div sandbox id=mysandbox div id=id DIV2 /div /sandbox /body from outside the sandbox: e = document.getElementById( id ); //e = DIV1 eMSB = document.getElementById( mysandbox ) e = eMSB.getElementById( id ); //e = DIV2 from within the sandbox: var e = document.getElementById( id ); //e = DIV2 Ric Hardacre www.cyclomedia.co.uk
Re: [whatwg] Targetting different anchors after submitting the form
Ian Hickson wrote: On Mon, 6 Mar 2006, Mikko Rantalainen wrote: Perhaps something along the lines form action=url input name=foo type=submit anchor=xfoo input name=bar type=submit anchor=xbar /form With WF2 you can just do: form action=url input name=foo type=submit action=url#xfoo input name=bar type=submit action=url#xbar /form indeed: 2.17. Extensions to the submit buttons ... In some cases, authors would like to be able to submit a form to different processors, using different submission methods, or not replacing the form but just updating the details with new data. For this reason, the following attributes may be used on submit buttons: action, method, enctype, replace, and target. ... if only i could figure our how to compile the firefox source (i've tried on three seperate occasions it's just far too complicated with all the extra garbage you have to install and configure first!) i could see this as something i could put in a local version to assist with making test-cases of the spec. ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
ROBO Design wrote: Is it too much to add a new attribute for something like this? Note that the server cannot see any of these anchor urls. Only the UA is able to scroll to correct position after receiving output from the server. Maybe adding an attribute for this sole purpose is too much to ask for. There are isolated cases where this is needed (I myself didn't need this ever). You can, however, modify the action of the form via DOM, by having an event listener for the submit event. I suppose you've used this. I've used multiple submit buttons myself in a couple of ways, most recently this has been used in an order enquiry search form where the admin can list orders by order no, customer order no, by customer or by product code. i do this by having one text input box and multiple submit buttons, and the client likes it that way very much indeed. a more everyday use i can think of off of the top of my head is this: form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form where the first button invokes the default form action (user hands over their cash) the second overrides it with it's own target page (converting the user's basket into a quote that they can refer to later and place as an order) the third submits the page back to itself (as per action=) but specifies an anchor to jump to (e.g. if the basket and totaliser is at the foot of the page) as an aside, if i could go back in time i would change the original spec so that the text displayed on a submit button is separate from the value submitted, thus: input type=submit name=ordertype value=sales text=PLACE SALES ORDER input type=submit name=ordertype value=sample text=PLACE SAMPLE ORDER input type=submit name=ordertype value=pro text=REQUEST PRO RATA INVOICE ric hardacre www.cyclomedia.co.uk
Re: [whatwg] Targetting different anchors after submitting the form
Anne van Kesteren wrote: Quoting ROBO Design [EMAIL PROTECTED]: ... form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form What's wrong with using the form attribute to point to multiple forms? One submits to one place, the other submits to another place. that might do it. can the data in my hypothetical cart belong to all the forms at once? ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] Targetting different anchors after submitting the form
Anne van Kesteren wrote: Quoting ROBO Design [EMAIL PROTECTED]: ... form action=order_place.asp input type=submit value=PLACE ORDER input type=submit value=SAVE QUOTE action=quote_add.asp#thanks input type=submit value=RECALCULATE TOTALS action=#here /form What's wrong with using the form attribute to point to multiple forms? One submits to one place, the other submits to another place. whoops, sent my last reply from the wrong from address, mod might ignore it but i've read the spec. if i want all the data in my basket to associate with my multiple forms i have to specify, for each and every one (unless there's some default=all forms possibility as opposed to default=none) the form thus input type=hidden id=prod_00_name value=pie form=saveform quoteform totalform input type=hidden id=prod_00_ea value=1.99 form=saveform quoteform totalform input type=hidden id=prod_00_qty value=4 form=saveform quoteform totalform input type=hidden id=prod_01_name value=beer form=saveform quoteform totalform [several dozen other elements along the lines of the above] input type=submit value=PLACE ORDER form=saveform input type=submit value=SAVE QUOTE form=quoteform input type=submit value=RECALCULATE TOTALS form=totalform now obviously this is an extreme example; i could just associate all three forms with a fieldset and house my cart/basket within that. but the fieldset is a block element and it may well end up presenting a similar problem that moving the form definition to the head was meant to solve. (though in my first example i did use a block-level form). ric hardacre http://www.cyclomedia.co.uk/
Re: [whatwg] anchor(jump) DOM Event proposal
Flow of events:
- When the page is loaded, and an anchor event listener exists, the
anchor event will be fired after the load event. If there is no anchor
in the URL, the event.anchorName property will be an empty string.
- When an anchor link is clicked, the anchor event listener (if exists)
will be fired
- The event handler can get the name of the anchor via event.anchorName
(which will contain the string after the hash)
- If the return value from the handler is true, the traditional form of
operation (the jumping to the anchor) will occur next; otherwise, that
step is skipped.
- The UA should act as if the navigation has gone forward a page (add
history, etc).
- If the user navigates back and the previous page happens to be the
same page but a different anchor, the anchor event again will be fired
as if the previous anchor was freshly navigated to. The same logic
applies to navigating forward.
sounds good, and logical when compared with anchor and button onclick
for example.
to clarify, where would the event be attached by default? document or
window? i.e. would i
function myonAnchor( e )
{
if( e.anchorName )
switch( e.anchorName )
{
...
default:
return true;
}
}
document.onAnchor = myonAnchor;
---
Ric Hardacre
http://www.cyclomedia.co.uk/
Re: [whatwg] default select item that does not satisfy required attr.
Ric Hardacre wrote: from the web forms doc in the comment at the bottom: * have a way of marking the first option of a select as the default but have it not satisfy a new required= attribute on select so that you can have selects that require a valid value. my proposed solution: whoops, i bashed out my markup examples quickly and totally fooed up some of it, specifically i should have optgroup label=text, but anyway, they were supposed to demonstrate the default semantic, also if a better word can be used than default for the option flag then so be it. ric
Re: [whatwg] getElementsByClassName()
Shadow2531 wrote: I was *messing* around with 2 different *examples*. 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html That one supports: getElementsByClassName(string); getElementsByClassName(array); If the string has spaces in it, it's considered that nothing will match and returns null. If it's an array, all must be present for an element to match. 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html Now this one supports the same 2 types, but the string handling is different. The string is space-separated. So, with this second example, you can do: document.getElementsByClassName(aaa); document.getElementsByClassName([bbb, ccc]); document.getElementsByClassName(bbb ccc); (The second 2 produce the same result. The 3rd one might just be cleaner in certain situations) I'm liking what options the second example provides. (not necessarily the code as I just threw it together and didn't think about exceptions, optimization and code size. Plus I just used a global function for the example.) Do you agree with the string being space-separated? It seems to make sense at least for html where a classname can't have spaces. looks good to me, the only quirk of this would be that you cant choose class=foo bar specifically over class=foo with gebcn(foo bar) but if this is the stated behaviour then i guess that's ok. on a side note, it might also be worth stating that in this case gebcn(foo bar) should only return the class=foo bar element once, not twice (one instance for foo and one instance for bar). just for completeness ric
Re: [whatwg] oninput event
Christian Schmidt wrote: Quote from the current working draft (10 January 2006) http://whatwg.org/specs/web-forms/current-work/#the-change: UAs may delay firing the input event if the data entry is rapid. Authors must not rely on this event firing once for each key press, mouse input, or similar. I'm not sure what the intention is here. I assume key press, mouse input, or similar refers to whenever the control's value attribute changes, i.e. not key presses on arrow keys etc. UAs may delay firing the event, but are they allowed skip it? If UAs are NOT allowed to skip events, what is the purpose of delaying them? And what exactly does delaying mean (e.g. what is the value of the control's value attribute when the event eventually occurs)? If UAs ARE allowed to skip events, I think it is a reasonable requirement that the last event per control in a series of inputs is not skipped, so that e.g. oninput=output.value=value will always make the output control be in sync shortly after the last key press (but not necessarily while the user is typing rapidly). yes that's exactly the use i can foresee, i have this problem in an app I'm working on currently, we can either use onChange or onKeyPress to activate the totalizing function for a series of quantity and length boxes. (e.g. 12 at 4 meters, 8 at 3 meters, the total being the total metreage). neither event is entirely satisfactory, onChange only happens when the text box looses focus (which is not the usual behavior in standard windows apps and has been brought up in client consultation ass odd) and onkeypress would be overkill IMO and would also yield intermediate invalid results. e.g. if an input is changed from 8 to 12 the initial 1 of 12 would cause the total to go out of whack. so a good implementation of onInput would occur after onKeyPress and before onChanged and would be sensitive to the user's computer's typematic delay. ric
[whatwg] Forms: Submit only changed inputs
i mentioned this briefly in my introductory email and am interested in other people's views. my thinking is this: form send=all default behaviour, implied if send is missing form send=changed only send input elements that have changed (i.e. are different to the reset state of the form). this would exclude hidden elements, to enable the page autor to still track ownership of the form input data. my reasoning is this: i'm creating an HTML4 + CSS2 datagrid implimentation, the datagrid is quite large and i'm resorting to per-row editing to keep the overhead down (both in terms of client scripting and bandwidth). but if a user were to load the datagrid and change just on field the entire data set would be sent to the server. where one would either (a) validate all the data and overwrite the existing data or (b) cache the form info so that a quick comparison can be made before validation and db updating. if, instead you could simply get a set of id's (placed in hidden fields) and corresponding data you could just validate and save the changed fields with a lot less work e.g. input type=hidden name=000_id value=123 input type=text name=000_name value=john smith input type=text name=000_email value=[EMAIL PROTECTED] input type=hidden name=001_id value=456 input type=text name=001_name value=jane doe input type=text name=001_email value=[EMAIL PROTECTED] input type=hidden name=002_id value=786 input type=text name=002_name value=uncle sam input type=text name=002_email value=[EMAIL PROTECTED] if the user changes jane doe to janet doe i would recieve back 000_id=123 001_id=456 002_id=789 001_name=janet doe now i can see that only record 001 has any fields changed, validate accordingly, and hence update the name field for user 456. a non-compliant legacy browser would not see the distinction and send all fields, which makes no difference to a good server script as it would in effect be performing the (a) option mentioned earlier, only that client's response time would be effected. Ric Hardacre
Re: [whatwg] getElementsByClassName()
Dean Edwards wrote:
Jim Ley wrote:
That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need testing etc. you
have to have a reason to add a method.
A good API should expose a meaningful interface to its consumer. If we
are allowed to define data according to a skew on its structure (HTML
className) then the interface to that data should reflect this.
The getElementsByClassName() method has already been compared to the
getElementsByTagName() and getElementById() methods. class is another
way to slice the data. It is a core part of HTML, the language we are
extending.
To me, getElementsByClassName() is a missing feature of the DOM to
support HTML4. I'd be happy if that were fixed in HTML5.
I think this is a very clear explanation of the reasons to include it,
it's not as if we're discussing GetElementsByOnMouseOver() here. But
let's throw out a use case off the top of my head:
i'm making a shopping cart and each product has a checkbox next to it,
to select it for deletion, there are also other checkboxes on the page,
one to agree to the terms, another to sign up for the mailing list,
another to sign up for advertisements from our business partners,
another one up at the top right by a search box for a search option and
finally the select all for deletion checkbox. when i click on the
latter i want to check all the individual checkboxes for each product.
as they're in the basket i'm specifically styling them class=prodchck.
so to check them all all i need to do is:
function checkall()
{
var a = document.getElementsByClassName(prodchck);
for( var i = 0 ; i a.length ; i++ )
a[i].checked = true;
}
Re: [whatwg] getElementsByClassName()
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class=foo bar and class=bar foo is real, not
merely syntactic. a search for foo should pick up either but a search
for foo bar should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName(foo bar,foo tang,woo tang)
this use of explicit class matching could, however be considered an
advanced use of the function, with emphasis on the simpler:
2. getElementsByClassName(bar,tang)
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName(foobar)
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship(foo:firstChild)
what this would mean, therefore is that
5. div class=foo bar
would be selected by example 1. whereas
6. div class=foodiv class=bar
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
Re: [whatwg] getElementsByClassName()
Lachlan Hunt wrote:
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red.
According to which rules specified in CSS will that be the case?
Given that CSS (assuming you meant to use class selectors instead), all
three markup samples will be blue. The order of the class names in the
markup is irrelevant. The order of the rules specified in the CSS is
relevant and the latter rule of equal specificity takes precedence.
just checked it, i was wrong, oops!
ric
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Jim Ley wrote: the document of course shows no use cases at all. Is there some doubt that the ability to tag an arbitrary set of elements and later easily get an array of those elements is a useful feature for web development? I've yet to hear of an actual reason to do so, people keep saying it seems useful... If you would like use cases, I present all of the web pages currently using a JS implementation of getElementsByClassName based on getElementsByTagName(*) and some manual class name inspection logic. Yes, but they're all using it to attach events to every one of the class, which is why you have to look at use cases, the reason they're doing it is not because getElementsByClassName is missing, but because addEventListenerToClass or -moz-binding etc. are missing. It's the classic mistake of looking at making the workarounds easier, when you should be looking at making the underlying use easier. Jim. Hmm, i've used getElementsByTagName in the past couple of days, specifically to walk a table row's data cells to retrieve and write data. This was part of a HTML4 datagrid implimentation and the first time i'd found a use for said function. Having this alongside getElementById but missing out getElementsByClassName seems short-sighted to me. There may be a use we havent thought of yet, and it seems like a logical function to round out the family, rather than bloat. Ric
[whatwg] introduction, plus some form input ideas
hello, i'm an asp developer in the uk and have a couple of suggestions... no doubt selfishly to make my life easier one day :-) these could probably do with their own threads if they're deemed worthy of discussion but let's just throw them out there: 1. form tag: send=all , (default, send all fields to server in get/post) send=changed , only send hidden fields and fields that have been changed by the user the idea being that if i'm running a datagrid then there's no point sending a ton of data back and forth if the user only edits a couple of cells. but the hidden form data will still be needed in any case so i can still connect the data sent to the user who sent it! 2. select tag: selectedindex=[num] implicitly set the selected index, instead of having to parse all the option tags and insert a selected string, much easier to bind to server side data, an invalid value (such as -1 or greater than the number of option tags) would mean none are selected. this would obviously not apply to multiple-selects 3. input tags: validate=[regex] implicitly set a regular expression to which the inputted data must conform, so a value of regex=([0-9]*)\.[0-9][0-9] would (assuming my top-of-the-head regexp isn't totally fubar) only allow the user to enter a number in currency format (any number of digits, a full stop and two digits). though how to enforce it is another question, leave it up to the agent? simply not respond if any other key was pressed? would it need a hint to fill out default formatting too, appending the .00 if it is left off, etc. just a few, i'm eager to get web 2.0 forms into a much more usefull state than at present, and to not have to rely so much on javascript and css hacking to get things done! ric hardacre
Re: [whatwg] getElementsByClassName()
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class=foo bar and class=bar foo is real, not
merely syntactic. a search for foo should pick up either but a search
for foo bar should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName(foo bar,foo tang,woo tang)
this use of explicit class matching could, however be considered an
advanced use of the function, with emphasis on the simpler:
2. getElementsByClassName(bar,tang)
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName(foobar)
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship(foo:firstChild)
what this would mean, therefore is that
5. div class=foo bar
would be selected by example 1. whereas
6. div class=foodiv class=bar
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
