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).

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.

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.

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.

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.

Ok, what would e.g. the <area> element's requirements look like?

<area>'s update steps are to set <area>'s href content attribute to the serialization of <area>'s concept-UU-url.

I meant the other way around. When does its concept-UU-url come into existence? What should that requirement look like?

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.

Taking so I can take another crack at it.

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?

Nevermind, I just put all the boilerplate in the HTML spec. See diff in bug 20072.