<br><br><div class="gmail_quote">2009/2/11 Ian Hickson <span dir="ltr">&lt;ian@hixie.ch&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[...]<br><div class="Ih2E3d">
<br>
</div>&gt; &gt; &gt; 2) you depend on css3-ui, in CR stage, instead of becss, a very<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
&gt; &gt; &gt; early WD<br>
&gt; &gt;<br>
&gt; &gt; BECSS is actually probably more stable than CSS3 UI at this point.<br>
&gt;<br>
</div><div class="Ih2E3d">&gt; Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to<br>
&gt; Last Call in the near future? I&#39;m not sure. In the mean time, CSS3 UI is<br>
&gt; final, and waiting only for implementation.<br>
<br>
</div>CSS3 UI is very vague, and is going to need serious work before browsers<br>
are able to actually implement it properly. A lot of the vendor feedback<br>
at the time it was written was dismissed (e.g. it doesn&#39;t have a<br>
particularly useful or comprehensive list of appearances).<br><div class="Ih2E3d"></div></blockquote><div>Well, it is the *Basic* User Interface, that is, the bare minimum. All the rest is Advanced UI, that I hope one day we will have.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
&gt; &gt; &gt; 3) you don&#39;t block the binding property: I don&#39;t expect that<br>
&gt; &gt; &gt; applying an XBL binding on an element causes it to appear like a<br>
&gt; &gt; &gt; span (because it gets almost no default CSS)<br>
&gt; &gt;<br>
&gt; &gt; This is actually intentional. Experience with elements like &lt;fieldset&gt;<br>
&gt; &gt; that have styles that aren&#39;t expressed in CSS is that you end up not<br>
&gt; &gt; being able to restyle them properly if you desire. With &#39;binding&#39; we&#39;d<br>
&gt; &gt; be able to knock out the whole default rendering (including weird<br>
&gt; &gt; things with the children) in one go.<br>
&gt;<br>
</div><div class="Ih2E3d">&gt; The fact is that binding it the best way to apply a set of event<br>
&gt; handlers to an element. Having to tweak the computed style of a fieldset<br>
&gt; in order to find what properties are actually set and reproduce them in<br>
&gt; the binding, just to put a set of onchange handlers to lots of fieldset,<br>
&gt; does not look optimal.<br>
<br>
</div>I don&#39;t understand why you would need to know what properties are set, or<br>
what &#39;onchange&#39; has to do with anything here.</blockquote><div> </div><div>&lt;html xmlns=&quot;<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>&quot; &gt;<br>&lt;head&gt;<br>&lt;xbl xmlns=&quot;<a href="http://www.w3.org/ns/xbl">http://www.w3.org/ns/xbl</a>&quot;&gt;<br>
&lt;binding id=&quot;textboxes&quot; &gt;<br>&lt;handlers&gt;&lt;handler event=&quot;onchange&quot;&gt;window.alert(&quot;Hey! You changed my text box!&quot;); &lt;/handler&gt;&lt;/handlers&gt;<br>&lt;/binding&gt;<br>&lt;/xbl&gt;<br>
&lt;style&gt;input[type=text] { binding: url(#textboxes); }&lt;/style&gt;<br>&lt;/head&gt;<br>&lt;body&gt;&lt;form&gt;&lt;input type=&quot;text&quot; value=&quot;Change me!&quot; /&gt;&lt;/form&gt;&lt;/body&gt;<br>&lt;/html&gt;<br>
<br>At a first look, it just sets an onchange event handler to every input[type=text]. Using the HTML5 approach to widgets presentation, you would need to set the appearance to field on the bound element or it will look much like a &lt;span&gt;<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
[...]<br>
&gt;<br>
</div><div class="Ih2E3d">&gt; I mean that Firefox and Safari set the appearance property on the widget<br>
&gt; element, and it is visible from outside, and dynamically changeable at<br>
&gt; run time. The binding property instead contains an opaque and UA<br>
&gt; specific value, that is not intended to be changed from JS (to switch<br>
&gt; back and forth between widget types)<br>
<br>
</div>I expect we&#39;ll define actual values for &#39;binding&#39; in due course; that&#39;s<br>
mostly waiting on XBL2 getting implemented. I don&#39;t see why &#39;appearance&#39;<br>
would work better with JS than &#39;binding&#39;.<br><div class="Ih2E3d"></div></blockquote><div>Ah ok. I thought you wanted to leave that to be implementation dependent. This is completely different. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
<br>
[...]</div><div class="Ih2E3d">
<br>
</div>We&#39;ll probably change that to just use keywords in due course.<br><div class="Ih2E3d"></div></blockquote><div>So what should be the difference between appearance: field and binding: field ? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
<br>
[...]</div><div class="Ih2E3d"><br>
<br>
</div>It&#39;s a guide to Web browser vendors who wish to render things in a<br>
commonly accepted way.<br><div class="Ih2E3d"></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
&gt; I think that section is for<br>
&gt; - implementors of new UAs, that don&#39;t need to reverse engineer the<br>
&gt; competitor products in order to find the defaults<br>
<br>
</div>Right.<br>
<div class="Ih2E3d"><br>
<br>
&gt; - authors, that in this way know what to expect from the various UA with<br>
&gt; less testing, that sometimes is also impossible, eg. you cannot test the<br>
&gt; rendering of a mobile phone if you don&#39;t have a mobile phone<br>
</div><div class="Ih2E3d">&gt; Having somewhere written that hyperlinks should be blue, allows you to style<br>
&gt; the background-color to anything but blue.<br>
<br>
</div>The section is not really for authors (though I suppose authors might find<br>
it interesting, in the same way they might find the parser section<br>
interesting).<br>
<div class="Ih2E3d"><br>
<br>
[...]</div><div class="Ih2E3d"><br>
<br>
</div>Authors should act as if the default style sheet is something sensible but<br>
they don&#39;t know what. (Because that is in fact what the situation is, once<br>
you consider user style sheets.)</blockquote><div><br>That is, the rule for authors is &quot;not just act as the UA default style sheet was not present, but also act as if it was completely undefined or defined to something weird&quot;, so explicitily write it every time it may be dangerous, like for :link.<br>
</div></div><br>That&#39;s a completely different point of view. Thank you for clarifications, I&#39;ll write div { display:block; } and :link { color:blue; background-color:transparent;} in all my style sheets from now on.<br>
<br>Giovanni<br>