Rendering section feedback

On Mon, 2 Feb 2009, Simon Pieters wrote:
> 
> The rendering section should say that when scripting is enabled, 
> noscript should be hidden (we have bugs saying that this should be with 
> !important -- some pages want to have <noscript> be display:block when 
> scripting is disabled but leave it hidden when it's enabled, or 
> something).

Done.


On Mon, 2 Feb 2009, L. David Baron wrote:
> 
> It should probably also define what else is hidden.  I wrote a good
> bit about "hidden content" in
> http://dbaron.org/cdi-req/#restricted-subtrees .  (Maybe that's
> defined elsewhere, though.)

As far as I'm aware, I've defined everything that needs defining here (SVG 
and SMIL notwithstanding). In practice, there isn't much to define as far 
as I can tell.

If there are any specific cases that you would like me to look at and 
ensure are defined, please let me know. (Concrete testcases would be ideal 
here so that there's no ambiguity -- this is a confusing area.)


On Tue, 3 Feb 2009, Olivier GENDRIN wrote:
> 
> Event if noscript is a block element [1] in HTML 4.01, I think that we 
> should spec display: compact or run-in, because the noscript tag could 
> be used in an inline or bloc environment (I never used these values of 
> display, so I can't tell which one would be the best one).

I've left it as 'inline'.



On Mon, 2 Feb 2009, Simon Pieters wrote:
>
>   h1 { margin-left: 0.67em; margin-right; 0.67em; }
>   h2 { margin-left: 0.83em; margin-right; 0.83em; }
>   h3 { margin-left: 1.00em; margin-right; 1.00em; }
>   h4 { margin-left: 1.33em; margin-right; 1.33em; }
>   h5 { margin-left: 1.67em; margin-right; 1.67em; }
>   h6 { margin-left: 2.33em; margin-right; 2.33em; }
> 
> These should be margin-top and margin-bottom.

Fixed.


>   When a Document is in quirks mode, margins on HTML elements that
>   collapse with the top or bottom of the initial containing block are
>   expected to be collapsed to zero.
> 
> I think this should be more general, sort of like:
> 
>   :first-child { margin-top:0 }
>   :last-child { margin-bottom:0 }
> 
> ...but I haven't looked into whether that matches reality or not.

That CSS definitely doesn't match reality. I'm not sure if my english 
prose does either, though. Are there cases that I missed that aren't 
covered by existing CSS spec text?


>   table { text-indent: initial; }
> 
> This should also apply to input, textarea, select, option, optgroup and
> button.

Thanks, done.


On Mon, 2 Feb 2009, Simon Pieters wrote:
> 
>   dl > dd { margin-left: 40px; } /* margin-right, for rtl elements */
> 
> <dd>s not in a <dl> should still be indented.

On Mon, 2 Feb 2009, L. David Baron wrote:
>
> For what it's worth, in Quirks mode, Gecko does something quite a
> bit more complicated involving a forced line break and indentation,
> and makes such dd's display:inline.

On Mon, 2 Feb 2009, Simon Pieters wrote:
> 
> I realise that IE does that too, but is it required for Web compat? Opera
> doesn't and I'm not aware of any page breaking because of it.

I've just changed the selector to "dd", since that's what Webkit does too. 
(I never understood why fantasai did what she did for <dd> in Gecko's UA 
style sheet.)


On Wed, 4 Feb 2009, Simon Pieters wrote:
> 
> Consider
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cdiv%20align%3Dright%3E%0D%0A%20%3Ctable%20border%20style%3Dmargin-right%3Aauto%3E%3Ctd%3Ex
> 
> Should the table be left-aligned or centered?
> 
> AFAICT the spec says it should be centered.
> 
> In Opera it is centered. In IE8, Firefox and WebKit it is left-aligned.

On Wed, 4 Feb 2009, L. David Baron wrote:
> 
> Which spec?  If HTML5 says something here I think it should say 
> left-aligned.  The margin-right:auto on the table should override the 
> align=right on its parent.  (Do you see the same results if you specify 
> align=center on a grandparent, etc.?)
> 
> (I could see an argument for left aligned, but I don't think centering 
> is a reasonable compromise between one thing saying left and the other 
> saying right... what would you then do as a compromise between center 
> and left, etc.?)
> 
> align=right and align=left on DIV and similar can't be expressed using 
> existing CSS, although they could be expressed using the property 
> described here (which could be called 'block-align' if it were added): 
> http://lists.w3.org/Archives/Public/www-style/2007Nov/0071.html
> 
> Gecko implements this proposal as extra values on 'text-align', though.

On Wed, 4 Feb 2009, Simon Pieters wrote:
> 
> HTML5 says:
> 
>   The div, caption, thead, tbody, tfoot, tr, td, and th elements, when
>   they have an align attribute whose value is an ASCII case-insensitive
>   match for the string "right", are expected to right-align text within
>   themselves, as if they had their 'text-align' property set to 'right'
>   in a presentational hint, and to right-align blocks and tables within
>   them, as if their descendants had their 'margin-left' property set to
>   'auto' in presentational hints.
> 
> So
> 
>  <div align=right>
>   <table><tr><td>x</table>
>  </div>
> 
> is effectively the same as
> 
>  <div style="text-align:right">
>   <table style="margin-left:auto"><tr><td>x</table>
>  </div>
> 
> Now add 'margin-right:auto' to the table and it becomes centered.
> 
> 
> > (I could see an argument for left aligned, but I don't think
> > centering is a reasonable compromise between one thing saying left
> > and the other saying right... what would you then do as a compromise
> > between center and left, etc.?)
> > 
> > align=right and align=left on DIV and similar can't be expressed
> > using existing CSS, although they could be expressed using the
> > property described here (which could be called 'block-align' if it
> > were added):
> > http://lists.w3.org/Archives/Public/www-style/2007Nov/0071.html
> > 
> > Gecko implements this proposal as extra values on 'text-align',
> > though.
> 
> If we want HTML5 to match IE, WebKit and Gecko then I guess it needs to
> rephrase along the lines of the proposal for 'block-align' referenced above.

The spec should now sidestep this issue somewhat. (The previous text was 
saying more than it intended.) It's still sort of a mess though.


On Wed, 4 Feb 2009, Anne van Kesteren wrote:
> 
> Only Firefox (maybe WebKit?) seems to have display:block for multicol. I 
> could not find a browser that has it for spacer. So these two elements 
> should be removed from that list I think. (Thanks to Simon.)

Dropped multicol. Couldn't find mention of spacer in the rendering 
section.


> Since CSS does define the user agent style sheet concept and this 
> section effectively defines one for HTML. Can we not do away with 
> presentational hints therefore?

Because author-provided presentation hints are supposed to override the 
user style sheet.


> It should be noted explicitly that the general rule for flipping margins 
> does not apply to the img[align=...] case.

Fixed.


> The rules in the form of "table[...] > tr > td" should be removed as 
> legacy content does not depend on that.

I don't understand what you mean.


> x h1 { font-size: 1.05em; } should be x h1 { font-size: 1.50em; }.

Fixed.


> Only Opera and Internet Explorer support <basefont> but Opera and HTML5 
> support it differently (and incomplete) from Internet Explorer. We're 
> planning on removing our remaining support and I think it would make 
> sense if HTML5 did too (apart from parser support that is).

Removed.


On Thu, 5 Feb 2009, Anne van Kesteren wrote:
> 
> "`table[frames=void]" should be "table[frames=void]".
> 
> "table[frames=below] > >" should be "table[frames=below] >".

Fixed both.


On Thu, 5 Feb 2009, Anne van Kesteren wrote:
> 
> In the frames algorithm two references are made to the fieldset element. 
> That should be frameset.

Fixed.


On Thu, 5 Feb 2009, Lachlan Hunt wrote:
>
> In the Margins and padding rendering section, this CSS is given:
> 
>   dir, menu, ol, ul { padding-left: 40px; } /* margin-right, for rtl elements */
> 
> Presumably, either the comment should be changed to say "padding-right, 
> for rtl elements" or the style changed to 'margin-left'.

Fixed.


On Fri, 6 Feb 2009, Simon Pieters wrote:
> 
> The spec contains the following defaults for <figure>:
> 
>   div, dl, dt, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hr,
>   html, layer, legend, listing, menu, multicol, nav, ol, p, plaintext,
>   pre, rp, section, ul, xmp { display: block; }
> 
>   blockquote, figure { margin-left: 40px; margin-right: 40px; }
> 
>   th, figure > legend { text-align: center; }
> 
> Let's it...
> 
>    http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3
> 
> Hmm, not really satisfying for me. The captions are off. If you try 
> figure { float:right } the first one looks ok but the second looks 
> weird.

Removed centering of <legend>.


> I think <figure>s need a shrink-wrap width applied that ignores the 
> <legend>.

CSS doesn't really support that in a sane way yet.


> I thought the following rules would do what I want:
> 
>   figure { display:table; margin-left:40px; margin-right:40px }
>   figure > legend { display:table-caption; caption-side:bottom }
>   figure > legend:first-child { caption-side:top }
> 
> But the :first-child matches in this case which is not expected:
> 
>   <figure>
>    foo
>    <legend>bar</legend>
>   </figure>
> 
> One might think that the following solves this problem:
> 
>   figure > legend:first-child:not(:only-child) { caption-side:top }
> 
> ...but then the reverse problem appears:
> 
>   <figure>
>    <legend>bar</legend>
>    foo
>   </figure>

I don't want to use the table model here. That's just going to cause 
confusion one day.


On Fri, 6 Feb 2009, Boris Zbarsky wrote:
> 
> If the constraint we want can't be expressed in existing CSS, we should 
> perhaps not be expressing it in CSS, right?

Indeed, the rendering section doesn't limit itself to selectors at all.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 11 February 2009 03:07:57 UTC