Re: for telecon: ISSUE-23 @profile order

Hi Manu,

Sorry, but I'm not sure that many of these tests are correct.

But also, as I illustrate at the end, I think this may just come down
to wording.


On Thu, May 27, 2010 at 4:23 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 05/26/2010 04:45 AM, Toby Inkster wrote:
>> So my proposal is for RDFa Core 1.1 to state that profiles are handled
>> from right to left.
>
> I was curious to see what other attributes in HTML work like this:
>
> ID
> --
>
> <p id="one">...</p>
> ...
> <p id="one">...</p>
>
> The first ID declared wins, the rest are ignored. (Firefox and Chrome)

I don't think this is a good test, since you're not supposed to have
more than one @id. So in that context taking the first and ignoring
any others is reasonable behaviour by a browser, but I'm afraid it
doesn't tell us much about what authors would 'expect'.


> STYLE
> -----
>
> <p style="font-size: 18px; font-size: 8px; ">XYZ...</p>
>
> The last one declared wins (8px) (Firefox and Chrome)

Fair enough, but that's defined by CSS itself -- i.e., a separate
language, which could have had different rules if its designers had
chosen to do so.


> CLASS
> -----
>
> <p class="blue red">XYZ...</p>
>
> This one surprised me. red always wins, regardless of whether it comes
> first or last. (Firefox and Chrome)

I don't think this has anything to do with attribute value order, but
arises from the order in which you defined your CSS rules. It sounds
like you defined blue and then red in your stylesheet:

.blue {
  ...
}

.red {
  ...
}

@class is actually an example of 'all values apply', rather than
left-to-right or right-to-left. It's the same as @property and @rel in
RDFa.

To illustrate this, you could also have rules like these in your CSS:

.blue.red {
  ...
}

.red.blue {
  ...
}

They both amount to the same thing. (Except in IE6...don't get me started...)

Anyway, interesting but I'm not sure we're learning much here about
what authors expect from certain attribute values! My point is that
there really isn't a 'default mindset' and that what you expect is
rooted in the language that defines the contents of the attribute.


> <p class="blue" class="red" >
>
> The first one declared wins (blue) (Firefox and Chrome)

This is not valid, since you're only supposed to have one instance of
a given attribute. So how browser developers have chosen to implement
their algorithm doesn't really tell us anything about the 'default
behaviour' that authors would be expecting.


> Javascript
> ----------
>
> <p onclick="javascript:var a = 4; var a=5; alert(a);">...</p>
>
> Last one declared wins (5) (Firefox and Chrome)

This has nothing to do with HTML or attribute values -- priorities are
defined by JavaScript.

So for example, if I re-wrote your example like this:

  onclick="javascript:var a = 4; (function(){ var a = 5; })(); alert(a);"

you would now be in a 'first one wins' situation.

Of course the point is that you need to know the language in the
attribute to know what is happening -- 'left-to-right' and
'right-to-left' rules are too simplistic, and no author would expect
them to work in this context.


> So, it seems like for attributes, the first one declared wins.

But duplicate attributes are invalid...


> For
> attribute values, the last one declared wins.

...that completely depends on the language used in the attribute.


> Since we're talking about an attribute value, we'd be going against the
> "last one declared wins" pattern that both CSS and Javascript uses. That
> may be confusing to Web authors.

Hopefully I've shown that the pattern is not as clear as you suggest,
and in the CSS and JavaScript examples, it completely depends on the
'language' that is used in the attribute, and not some more generic
rules.

By the way, I'm not saying that we /have/ to go with Toby's
suggestions if there are arguments against; the benefit to his
proposal is that it allows us to keep in sync with Microformats for
little or no cost to us, but there may be other arguments that we
haven't considered.

One last thing, I think you can still have a 'left-to-right' mindset
for this, if you choose the wording correctly.

Toby explained that the XMDP approach is to say that profiles
appearing first in the list are /more significant/ than those coming
later. That already points to a way of conceptualising this that is
'left-to-right'.

Of course, we've tended to explain it as a 'right-to-left' thing by
saying that profiles are loaded from the right, but that is actually
just an implementation detail. I could just as easily implement the
same functionality by loading all profiles from left-to-right and
ignoring duplicate entries -- that is after all what saying that the
left-hand profiles are 'more significant' means.

(Ant takes exactly this 'double-speak' approach; the documentation
talks about your ability to override properties by setting local
properties files, but the reality of the implementation is that once a
variable has been set, it can't be changed.)

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 27 May 2010 08:22:10 UTC