- From: Sander <svl@juima.org>
- Date: Sat, 26 Jun 2004 10:31:48 +0100
Ian Hickson wrote: > How about this? We say that all attributes are processed, except those > starting with the two character string "[]", which just have their two > leading square brackets removed and are otherwise untouched. > > Then any unsafe attributes can just have "[]" put at the front. > > Ugly, but at least we don't have a weird attribute and a list of magical > attributes that get processed... I've been mulling this over for a while, but I like it even less than my "magical attributes" solution. The main reason for this is found in content management systems (as I create them), where roughly up to 95% of all input elements will potentially contain user-submitted data. Always in the value attribute of course. Using the [] solution, this means that I'd have to go and insert that into pretty much every input element. That's a lot of bother. Much better to filter more broadly, aka on specific attributes. If your objection to the "magical attributes" stands (I'm not saying that it isn't bad, but I do think that authors will be able to deal with it; after all, it's not that different from for example CSS, where things like the margin property are applied to a 'magical' list of elements, and that even differing per UA), then I would propose to go back to your original proposal, with an "excludeparsing" attribute containing a comma-seperated list of of those attributes of descendant elements in which [id]-replacement doesn't happen. (That said, I can most certainly live with the [] solution - I just think than in reality I'll hate it over alternatives.) Let's see - related to this, I've seen a proposal floating by to not do [id]-replacement at all. I strongly oppose that. Right now I can drop in the template, <repeat> elements and add/remove buttons in pretty much all applications where I'd want to use them, to vastly simplify the client-side code, and I wouldn't have to change a single line of the backend. It fits perfectly. If I'd somehow have to go and parse a list of values with the same name (or be forced into automatic appending of .[id]), I don't think I'd bother with repeat templates at all. I do like the <template> element proposal for better degradability. >> That's throwing away the ability to specify logarithmic numbers. Not >> used very often admittedly (at least in my experience), but the >> possibility of them is very welcome nonetheless. > > We can add them back if there really is a good use case. I haven't seen > one, to be honest. I haven't yet thought of a "really good" usecase, but just its inclusion in the original spec has allowed me to envision dozens of potentially interesting uses to explore. Most being one variation or another of 'navigation' through anything containing very large amounts of data. For example, a weblog as it will exist 10 years from now: showing a logarithmic range to jump back 1, 2, .., 9, 10, 20, .., 90, 100, 200, .., .., 3000, 4000 days. (Or 'posts' on a message board if the objection to that would be that it could better be done with a date element.) >> I'm personally leaning toward the earlier suggestion of a list of >> datetime-part values ""y,m" for expdate, "y,w" for week, "y,m,d,h,M"" >> (which you called "nice and generic, but ... much more complicated"), >> but extended to (for example) "h,15M" - which would specify a precision >> of 15 minute increments for a time consisting of hours and minutes. I >> think authors will be more than willing to put up with the complexity of >> this (I know I would be) to have just one general purpose datetime >> element which can deal with all the weird requirements which comes up in >> actual use. > > Is the current text (using step) acceptable? Acceptable? Yes. (Hell, I'm overjoyed just having _something_ for this in there.) :) Do I like it better than what I was proposing? No. :) Though this is mostly a result of not liking so many elements for what I see as just different aspects of the same one datatime input element. Use case: a nature photography website with a list of national parks: asking users for each "what is the best month of the year to visit this park?" input type="month" is 'useless', as it includes a year (this usecase makes me realize I liked it better when it was called expdate, as that name at least suggested the existence of the year). So the website will use a regular select, throwing away the semantics of "date" (with additional side-benefits like the user-agent localizing the names of the months). You could of course add yet another datetime-derived input value for "just month" (and then someone else would come up with a usecase for "just day of the month plus time in hours" (monthly meetings?)), but that's exactly my objection. I think there are already too many input types now, when it could all be done with <input type="datetime" part="m">, which is extensible enough to cover every use case that hasn't yet been thought of, can easily include step for datetime cases, and thus allows for the current step to be reverted back to what it was when it was still called precision. I realize a lot of this last part has been brought up in some form or another already, so I won't go and become a pain by continuing to argue for it if you stick with the current solution, but I do think it'd be worthwhile bringing up at least once more. Thanks, Sander
Received on Saturday, 26 June 2004 02:31:48 UTC