20927 2013-02-09 01:39:15 +0000 "update steps" 2013-04-09 18:13:18 +0000 1 1 1 Unclassified WHATWG URL unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 ian ian ian mike sideshowbarker+urlspec oldest_to_newest 82820 0 ian 2013-02-09 01:39:15 +0000 http://url.spec.whatwg.org/#concept-uu-update Please invoke the update steps with a "new output value" (the serialisation of /url/, probably). 82874 1 annevk 2013-02-10 11:01:45 +0000 You could just forward the object's url concept. I think that's going to be the solution long term, so that e.g. fetch does not have to parse a string again (although you will need to serialize it to set the href content attribute). 83072 2 ian 2013-02-13 00:08:54 +0000 I don't mind if you send me the absolute url or the parsed url, I just want the value somehow. (If you send me the parsed one, I'll just serialise it.) I don't have the value anywhere on my side since the /url/ object doesn't exist except in the mind of the URLUtils spec. 83090 3 annevk 2013-02-13 07:13:49 +0000 If there's no object then all kinds of algorithms in the URL Standard will fail. Pretty much all the attributes depend on there being an object they can return or modify bits from. 83115 4 ian 2013-02-13 19:42:21 +0000 Can't you maintain the object on your side? On my side I just have a string, e.g. a content attribute. It seems silly to have the content attribute also have to define that it maintains some object state and so on when it's really just a string at the end of the day. 83119 5 annevk 2013-02-13 20:01:36 +0000 Well, ideally we parse these only once. So you'd pass e.g. a parsed URL to Fetch rather than having Fetch parse it again. Given that it's the object that implements URLUtils that has the associated url, you should be able to just access it without having to do bookkeeping yourself. 83125 6 ian 2013-02-13 22:41:17 +0000 Ok, what would e.g. the <area> element's requirements look like? 83139 7 annevk 2013-02-14 11:54:13 +0000 <area>'s update steps are to set <area>'s href content attribute to the serialization of <area>'s concept-UU-url. 83173 8 ian 2013-02-15 02:02:12 +0000 I meant the other way around. When does its concept-UU-url come into existence? What should that requirement look like? 83192 9 annevk 2013-02-15 11:49:00 +0000 It's always in existence effectively (because <area> implements URLUtils), but initially null, until initialized through the "set the input" algorithm, at which point it could still be null I realize now if parsing failed. In which case you want to grab input. This happens if someone would set <area>.href to http:test:test. So <area> would say that on creation you run the "set the input" algorithm if there's a href value. And when the update steps are run you check url and if it's null you use concept-UU-input and otherwise you serialize url. 83604 10 ian 2013-02-23 00:41:04 +0000 Taking so I can take another crack at it. 85799 11 ian 2013-04-09 17:45:48 +0000 I really think it would be better if the "update steps" were invoked with a value that just took care of all that, unless there's some reason that the behaviour should be different for different cases? What strings would case a parse failure so I can test it? 85812 12 ian 2013-04-09 18:13:18 +0000 Nevermind, I just put all the boilerplate in the HTML spec. See diff in bug 20072.